Not happy with the issues feed from Google

Hello,

I'm not happy to see the feed subscribed to this mailing list.
I often have to use the web interface to this list, and the number
of one-line comments and status changes makes for a very
unpleasant reading experience.  In addition it makes it more
difficult to find the interesting discussions. As a workflow,
it also has problems, as reply mails are not added back to the
issue tracker.

Stephan

> I'm not happy to see the feed subscribed to this mailing list.


+1

Why not create Pharo-project-issues and initially subscribe everyone on this list but let people unsubscribe from that but continue to follow the discussions here.

> As a workflow, it also has problems, as reply mails are not added back to the issue tracker.

I'm more equivocal about this statement.

../Dave

Remember that most email client support filters. You can easily create one.

Cheers

Mariano

+1 too

Though I created filter in my web client declining such messages, I
still think that for newcomers or people searching the net this is not
good to see all that stuff. It's very easy to get lost in this heap of
emails. What's the idea behind it?

2010/11/18 Dave Mason <[hidden email]>:

Mariano wrote:
> Remember that most email client support filters. You can easily create one.

- That doesn't help with the web interface;
- My mail client supports RSS feeds, the added value of a duplicate is low;
- Filtering doesn't work with digests;
- The subject is not good and the content is not good for a mailing list;
- It reduces the searchability/usability of the mailing list archives;

Stephan

On 18/11/10 11:52 AM, Stephan Eggermont wrote:
> Mariano wrote:
>> Remember that most email client support filters. You can easily create one.
>
> - That doesn't help with the web interface;
> - My mail client supports RSS feeds, the added value of a duplicate is low;
> - Filtering doesn't work with digests;
> - The subject is not good and the content is not good for a mailing list;
> - It reduces the searchability/usability of the mailing list archives;

I agree with all these points. IMHO, mixing auto-generated messages with
"live" messages is not a good idea.

--
Yanni

El jue, 18-11-2010 a las 12:14 -0500, Yanni Chiu escribió:
Can this be configured so that only the issue creation and closure are
notified to the list, and not all the modifications to the issue?


--
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx

On Nov 18, 2010, at 6:17 PM, Miguel Cobá wrote:

I do not think so

there is a mailing-list for newbies.

Stef

On Nov 18, 2010, at 5:22 PM, George Herolyants wrote:

On Nov 18, 2010, at 5:53 PM, Stephan Eggermont wrote:

> Mariano wrote:
>> Remember that most email client support filters. You can easily create one.
>
> - That doesn't help with the web interface;

??

> - My mail client supports RSS feeds, the added value of a duplicate is low;

But you just get a bad summary from squeak-source I have to click on the link all the time.

> - Filtering doesn't work with digests;
I do not understand

> - The subject is not good and the content is not good for a mailing list;

Why
Bugs are our concerns

> - It reduces the searchability/usability of the mailing list archives;

Why?
I want to look for bug discussions there too and not using a bad google search engine.

>
> Stephan
>

+1

Sorry guys this is not optimal but after been against when I see it in squeak, I'm in favor because it
helps understanding what is happening.

Sorry to be blunt but
****YOU**** yes you guys do not look at the bug or bug fixes in general.

So often ME myself and I, have to send email about point from the archive to the mailing-list.
Often I do not even see that a bug has been posted and YES I have 5 rss feed and I read them all.

What is the last time you read the bug archives to see what is happening there?
So if you do not read the archive then how can you help? how can we make sure that people are aware?

What is the last time you look at the code of the fixes that got integrated? Because if you do not read
it how can we do quality control? So if I could I would send the diff of all the package in the mailing-lits as this is done in squeak.

Now what we can do to please some of you so far 4, we could create a mailing-list where such mails would be sent.
But let us see so far who is really against.

Stef


> Remember that most email client support filters. You can easily create one.
>
> Cheers
>
> Mariano

+1
i don't read all mails, but at least by seeing in subject, i have an
idea that there are some activity around some issue.

Also, in case if something attracts my attention, where i feel i can
be helpful, i can easy click on message and read it.

In contrast, when all tracker activity is hidden inside issue tracker,
i have no chances to be aware who doing what and
what problem is attacked by people, unless i cc-ed to this issue as well.
'Tracking' tracker by manually inspecting every single issue is time sink.
So, i think couple of extra lines in mails list worth it, because it
helps to people to be aware of what others do.
Of course i'm not happy with it as well.
Most messages are not quite informative , but its up to those who
posting them: make posts more elaborate , so others could understand
what is it about, where the problem etc etc.

On 18 November 2010 19:33, Stéphane Ducasse <[hidden email]> wrote:


--
Best regards,
Igor Stasenko AKA sig.

2010/11/18 Stéphane Ducasse <[hidden email]>:
> What is the last time you read the bug archives to see what is happening there?
> So if you do not read the archive then how can you help? how can we make sure that people are aware?

Stef,

I'm subscribed to some issues through standard Google Code "star this
issue" feature. So, I'm aware of the changes happening to these bugs.
I'm also subscribed to the RSS channel of the Pharo Google Code site,
but I do not follow it closely so far -- just have not enough time. So
my point is that interested people still are able to follow the
bugflow without subscribing the whole list to the updates.

And if you want to make sure people are aware of the work you're
doing, I'd rather recommend you to pay more attention to the news page
of the pharo-project.org website. And having a list of immediate goals
and time line for them could also help, I think. Forcing people to
follow all the minor activities happening on the tracker (I mean
changing milestones, statuses and so on) won't rather help (IMHO).
I've also created a filter to ignore all such messages after I've seen
them flooding my inbox. So I even don't see them and this fact somehow
contradicts to your point of making people aware. I still think
important things are worth talking abouth them. I mean bootstraping
from kernel or new compiler or something else but in the form of
goals, plans, progress made and so on. Yeah, I know it's easier to
speak than actually do :), but effect might be better.

You may now ask, why I'm so concerned about this issue, if I do not
even receive these autogenerated emails :) Ok, I just think that it's
wrong. But I may be wrong too of course :) There are two things I find
not practical. One of them is that replying to autogenerated mail in
the list and not copying these replies to the tracker actually splits
the discussion and makes it harder for people to track it later. The
other thing is mailing list archives like the one on Nabble. It's just
becoming harder to surfe them. And I'm not aware of the other
opensource projects doing the same with their mailing lists.

> What is the last time you look at the code of the fixes that got integrated? Because if you do not read
> it how can we do quality control? So if I could I would send the diff of all the package in the mailing-lits as this is done in squeak.

You can't do quality control this way. Everyone won't look at the code
of these fixes, interested people are already looking at them so you
won't gain anything. And it's iterative process after all: you make
changes, people look at the code of these changes doing their job in
Pharo, and if they're unhappy with these changes you'll know about it
:) But important changes still need to be reviewed by experienced
community members, no doubts here.

> Now what we can do to please some of you so far 4, we could create a mailing-list where such mails would be sent.
> But let us see so far who is really against.

Don't get me wrong, I'm not extremely against this change. I just
think that this is not the best way to achieve your goals.

My apologies for the long mail.

George

Stef wrote in reply to:
>On Nov 18, 2010, at 5:53 PM, Stephan Eggermont wrote:
>>That doesn't help with the web interface;
>??
As I said, I often browse
http://lists.gforge.inria.fr/pipermail/pharo-project/2010-November/

>>But you just get a bad summary from squeak-source I have to click on the link all the time.
But then you at least get to see the whole discussion instead of one line.

> - Filtering doesn't work with digests;
>>I do not understand

The mailing list has a digest function. Most email clients do not know how to
filter them.

> - The subject is not good and the content is not good for a mailing list;
>>Why
>>Bugs are our concerns

I fully agree that bugs are our concern, and that it is important to make
activity visible. I also understand and share your frustration that bug
reports are badly read and written. I just think that this works contra-productive.
- the subject of a feed message is bad: it is just the issue number
and the issue title, instead of adding what happened with the issue.
- the content of a feed message is bad: the context is missing.

> - It reduces the searchability/usability of the mailing list archives;
>>Why?
>>I want to look for bug discussions there too and not using a bad google search engine.

I think the problem most potential contributors have is one of too much information,
not too little. Giving them more, in a badly prepared format, is unlikely to help.

Stephan

Yes, please keep it!

(And mails with code diffs would be great too...)

Adrian


On Nov 18, 2010, at 18:33 , Stéphane Ducasse wrote:

On 18 November 2010 22:38, Stephan Eggermont <[hidden email]> wrote: i think its because you turned it on just recently.
For new issues, all messages will probably be gathered into a single
thread by mailing client,
so by opening it, everyone could be able to read a whole issue from
very starting, without a need to visit an issue tracker.
(btw, to test that,  create a new issue)

>> - It reduces the searchability/usability of the mailing list archives;
>>>Why?
>>>I want to look for bug discussions there too and not using a bad google search engine.
>
> I think the problem most potential contributors have is one of too much information,
> not too little. Giving them more, in a badly prepared format, is unlikely to help.
>
> Stephan
>



--
Best regards,
Igor Stasenko AKA sig.

As an option, we could rely mails to a mail bot, which will format a
message more nicely,
by changing the topic and removing other stuff, and then resend it to
mailing list.
Or ask google staff to gives the way how we can customize it.


--
Best regards,
Igor Stasenko AKA sig.

>>>
>
> I fully agree that bugs are our concern, and that it is important to make
> activity visible. I also understand and share your frustration that bug
> reports are badly read and written. I just think that this works contra-productive.
> - the subject of a feed message is bad: it is just the issue number
> and the issue title, instead of adding what happened with the issue.

I guess that you do not really measure the amount of work it can represent.
The only way to be able to do that is to force people to write better bug tracker description and guess
not a lot of people open a bug entry so a core of people is again doing that.

> - the content of a feed message is bad: the context is missing.
>
>> - It reduces the searchability/usability of the mailing list archives;
>>> Why?
>>> I want to look for bug discussions there too and not using a bad google search engine.
>
> I think the problem most potential contributors have is one of too much information,
> not too little. Giving them more, in a badly prepared format, is unlikely to help.

We will see but what if it helps the contributors and make them more productive?

So may be the solution is to add another mailing-list. what is clear for me is that
I would love to get the changes like in squeak in the mailing-list in addition to all the bugtracker
activity.

Stef

I asked for the creation of bugtracker list

>>
>
> Stef,
>
> I'm subscribed to some issues through standard Google Code "star this
> issue" feature. So, I'm aware of the changes happening to these bugs.
> I'm also subscribed to the RSS channel of the Pharo Google Code site,

same here

> but I do not follow it closely so far -- just have not enough time. So
> my point is that interested people still are able to follow the
> bugflow without subscribing the whole list to the updates.

yes but you have to individually register.

>
> And if you want to make sure people are aware of the work you're
> doing, I'd rather recommend you to pay more attention to the news page
> of the pharo-project.org website.

We cannot do that if this is not automated. Then the news are reviewed by native english speakers.....
Probably we should have a dev news where we could push the issues comments but so far I do not know if this is possible

> And having a list of immediate goals
> and time line for them could also help, I think.

Yes this is why I propose a IRC monthly meeting

> Forcing people to follow all the minor activities happening on the tracker (I mean
> changing milestones, statuses and so on) won't rather help (IMHO).
> I've also created a filter to ignore all such messages after I've seen
> them flooding my inbox. So I even don't see them and this fact somehow
> contradicts to your point of making people aware.

So other people just read them. I have a filter and I read them in batch.
Sometimes just passing 0.5 s on an issue.

> I still think important things are worth talking abouth them. I mean bootstraping
> from kernel or new compiler or something else but in the form of
> goals, plans, progress made and so on. Yeah, I know it's easier to
> speak than actually do :), but effect might be better.

Yes we do not want to replace the communication :)


> You may now ask, why I'm so concerned about this issue, if I do not
> even receive these autogenerated emails :) Ok, I just think that it's
> wrong. But I may be wrong too of course :) There are two things I find
> not practical. One of them is that replying to autogenerated mail in
> the list and not copying these replies to the tracker actually splits
> the discussion and makes it harder for people to track it later.

Yes true
may be we will need more discipline.

> The other thing is mailing list archives like the one on Nabble. It's just
> becoming harder to surfe them. And I'm not aware of the other
> opensource projects doing the same with their mailing lists.
>
>> What is the last time you look at the code of the fixes that got integrated? Because if you do not read
>> it how can we do quality control? So if I could I would send the diff of all the package in the mailing-lits as this is done in squeak.
>
> You can't do quality control this way.
Oh yes believe you do.
I will tell you a small story that explained why I was mad against 3.10 process.
One guy that is in network/web sent a fix and I thought as a 3.9 integrator that I would integrate it.
Then bert reviewed the fix and said that this was bogus so it was not integrated in 3.9.
In 3.10 there was little communication about bugs and I raised this concerned to the squeakfoundation board.
Because if experts do not have access fast to what is happening then they will not look at it then your overall quality will
decrease. This is why I really want the new recentMessage browser because it is gorgeous and I want to use it daily
especially when others are doing integrations ( we want to open the process ).


> Everyone won't look at the code of these fixes, interested people are already looking at them so you
> won't gain anything.

No this is where you are wrong. People are not. I have to add lukas in the bug entry manually ....
I have to ask personnally people to look at specific issue.


> And it's iterative process after all: you make
> changes, people look at the code of these changes doing their job in
> Pharo, and if they're unhappy with these changes you'll know about it
> :)

No because when you have time you do not look at other code. You hack your own great stuff.

> But important changes still need to be reviewed by experienced
> community members, no doubts here.
>
>> Now what we can do to please some of you so far 4, we could create a mailing-list where such mails would be sent.
>> But let us see so far who is really against.
>
> Don't get me wrong, I'm not extremely against this change. I just
> think that this is not the best way to achieve your goals.

Thanks for sharing that with us.
We will create a separated mailing-list to see how it works.
>
> My apologies for the long mail.
>
> George
>