On Thursday 21 October 2010 10:47:49 pm Ian Clarke wrote: > Obviously there is a lot of frustration about the bugtracker. I think the > root of this frustration is the following three problems: > > 1) A lack of consensus as to what means what (eg. does the mere presence of > an open bug imply that it must be fixed?)
No, this is no problem. It is very clear in fact: - If something has target version == next version, it must be fixed OR assigned a different target version - If something has no target version, it must be reviewed and assigned one. If its not possible to assign one, it must be set to category "feature" since it is no bug then. > 2) A lack of consensus as to who is responsible for what (who decides what > must be fixed?) This is also a non issue. The person who is assigned the issue is responsible for getting it fixed ASAP. The community of the people who monitor the issue and respond it can influence the decision. If nobody gives a shit about commenting on the issue, the person who is assigned the issue can just dictate the decision. This is pragmatic and it works very well with projects based on volunteers: Anyone who steps up to get something done can decide about how to do it as long as nobody complains. > 3) The bugtracker is permitted to get out of sync with reality (caused by 1 > and 2) This is a symptom, and the cause is the real problem: Nobody USES the bugtracker. There is NO technical problem as the ones you have mentioned. The problem is pure LAZINESS. We can fight the problem by enforcing people to use it with the following policy for releasing new versions which I have proposed in the previous mail: ============================================ 1. ALL issues with the given target version in the bugtracker must be resolved, closed or assigned a different target version. NO release with a single open issues in the roadmap page (= with the given target version). 2. NO release if there are any issues with block/crash severity and no target version. They must be assigned a target version first, which will cause rule 1 to hit maybe. ============================================ Even if people abuse the rules and just change the target version of all issues they will at least have to look at them and feel the guilt of not dealing with them :) > > For 1), I think the best philosophy is to keep things as simple as > possible. What is the purpose of a bugtracker? > > I would say its as a record of what problems people have discovered, and > also a snapshot of what tasks must be completed in order to meet some > target event (currently the 0.8 release). I think these two roles get > confused - simply recording a problem should not immediately create an > expectation that it will be fixed. That determination should probably be > made only by someone actually willing and able to fix it. It should generate the expectation that somebody at least LOOKS AT IT. That is what is missing here: I've reviewed a shitload of issues, the result is that there are ~400 issues with target version 0.8 now, and people, especially toad, refuse to at least read them and decide about whether target version 0.8 makes sense or not. There is NO problem with open issues as long as they are reviewed and assigned a very far-in-the-future target version OR "priority = none", "severity = feature".... THIS does not happen... bugs are not even being flagged as "this CAN stay open".... > > I think we should probably try to have a weekly "bug-scrub", where we > quickly go through all outstanding bugs and confirm that any associated > metadata (time estimates, completion status, target milestone, assignee > etc) is correct. This process has worked well for me in other > environments, although they were commercial, not voluntary. As for > whether this should be over IRC, or perhaps over Skype I'm not sure, my > past experience it was all verbal and that seemed to work nicely. > This is a VERY bad idea: The meetings will take at least 1-2 hours of FUD wars & nonsense discussions where NO code is written at all. People do not write code during meetings. The effect of the meetings will be lots of wasted time which could have been spend at actually RESOLVING issues instead of just discussing about them. Because there IS nothing to discuss (!!!!!!!!!!!!!!!!!!!!!!!!!!), most issues are very easy to decide about when they should be done, the problem is that the actual programming does not happen. Especially on the minor issues... We have a shitload of minor bugs which each would only take 10-15 minutes of programming.... - It would be much more of a use if certain people (we know who I mean :) promised to spend a fixed amount of time (1 hour) per workday at working on issues on the roadmap page.... this would decrease the amount of minor, quick- fixable issues very fast.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
