Saturday, June 8, 2013

Re: Overuse of "AssumedStale" Issue Tag

Hi Thomas. I have two comments that I hope you will find helpful:

 * I think most of the blowback from this could have been prevented with a little more communication. Yes, it's common for big projects to clean out stale bug databases by closing everything and re-opening issues when stakeholders speak up - but it's a good idea to folks know the procedure. Just putting "speak up if you think this issue is still appropriate" in the closing comment would have been enough.

 * It appears that you're using NotPlanned as a "polite" form of WontFix. This is a bad idea because it looks like a priority setting; there is already a Priority tag. WontFix is an appropriate response to issues which are considered to be outside the scope of GWT core, but NotPlanned is being misused for issues which are clearly within the scope of GWT core but simply not prioritized.


This is clearly within the perview of GWT core; it can't be implemented as a plugin, it would bring value to GWT, and there are some nonzero number of people who would like to see it addressed. I totally understand that it is not a priority for the GWT development team... so why not leave it open and deprioritize it?

I fear that using NotPlanned instead of WontFix confuses low-priority issues with "shouldn't be planned" issues. It's very important to maintain a distinction between the two.

Thanks,
Jeff



On Tue, Jun 4, 2013 at 2:11 AM, Thomas Broyer <t.broyer@gmail.com> wrote:


On Tuesday, June 4, 2013 10:19:27 AM UTC+2, Davide Cavestro wrote:
@Ed
I really hope you are right... but so far I've had the same feelings of Mauro and David
I guess some discouragement/vexation could be avoided adding an explanatory comment before or contextually tagging an issue as AssumedStale, and especially avoid stating
I spent more than half an hour reading the code and the specs and doing tests. We can't realistically spend as many time on each and every opened issue. 
That really makes me wonder...

The quote above is out of context: it was a reply to Mauro's "This is the kind of feedback I would have appreciated before setting the AssumedStale keyword."

So let's try again:
  1. the issue tracker has been neglected for years, leading to many issues open and never triaged; we need to clean that up
  2. we can't realistically spend half an hour for each and every of these issues: 1500 issues or so would take 750 man×hour, and nobody works full-time just on this (that'd be 100 workdays, i.e. 5 months, if one person were dedicated full-time verifying issues before closing them; surely we can spend everyone's time better)
  3. so as Ray Cromwell says, the only viable option is to "crowd source": when in doubt, close the issue and see if someone complains, and then only spend time on that issue.
Then we have to set priorities, because we're not paid to work on GWT (some Google employees are, but their priorities are the ones of Google; this is the reason why the issue tracker had been neglected for so long and why Google chose to make GWT more open by forming the Steering Committee).
On the issue Mauro points out and many others where Daniel replies with "feel free to provide patch", we can reopen it but if nobody spends the time to fix it, in a year from now we'll have the same mess in the issue tracker. On that specific issue, I could change the status to NotPlanned (so it's still closed, but removes the word "stale") but would it change anything to the way the issue is handled after that? No. (though if you think NotPlanned would be better than AssumedStale, I can make that change).

I've had issues open for years, patches pending review for months. I've been there. Daniel also closes some of the issues I reported some time ago [1], and my response is to post patches: e.g. https://code.google.com/p/google-web-toolkit/issues/detail?id=6227
I understand that everyone does not have the GWT sources setup to hack on them, so I don't expect patches coming that fast after an issue has been closed, but at one point this is something you'll want to do. I report issues on other projects too, and when possible I try to provide patches (particularly if that's blocking me for my job). I don't expect every patch to come without prior discussion either: if you're not sure how to fix something, ask on the gwt-contrib group and we'll try to help as best as we can.

(and this is in addition to also providing patches for other issues –e.g. https://code.google.com/p/google-web-toolkit/issues/detail?id=8171–, following comments on the issue tracker to help Daniel in triaging issues –the reason I answered on Mauro's issue–, follow the group and stackoverflow, etc. and everything being done mostly during my free time –most issues I reported were for projects at work–)

Put differently: we're all in the same boat!

BTW, I'm with Ed here: there haven't been as many external patches since we moved to Gerrit and started closing issues and asking for patches; and the move to Gerrit really speed up the review process.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
at

No comments:

Post a Comment