On Friday 22 October 2010 09:56:40 pm Ian Clarke wrote: > On Fri, Oct 22, 2010 at 7:43 AM, xor <xor at gmx.li> wrote: > > 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. > > So if its clear then you and everyone else must understand, for example, > the difference between severity and priority. Do you? Does everyone? > Obviously not, in which case there is at least one thing that certainly > isn't clear about the bugtracker.
Severity is what is broken by the issue, priority is how fast we plan to fix it compared to other issues. What is the problem? > > > 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. > > It obviously is an issue, who decides who the bug is assigned to? Its decided in a community process :) If the person who is assigned the bug doesn't plan to finish it any soon others can take over. Further, for issues which are on the roadmap, toad should periodically check whether the assigned people have made any progress, unassign them if not. - Fred is the primary project of the FPI and toad is the manager of all issues about fred so he should stick to the roadmap and review it and unassign people if they don't finish their issues. Also, we have pre-configured auto-assignments for each category in the bugtracker... I get all Freetalk bugs, toad gets all fred bugs, etc. > > 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. > > That is all very well, except if you were right then our bugtracker would > be working just fine - but its not, so you are wrong. > Right about what? The statement which you are trying to prove wrong is not obvious from what you have cited here. > > 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. > > By whom? You can't just decree things and expect them to happen. Well since toad is being paid to develop fred I guess it's his responsibility in the fred bugtracker at least, and aswell in projects which we consider crucial for the next fred release. > > > 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. > > "generate the expectation" is meaningless, you have to define a process or > you can made demands and tell people what the "expectation" is until you > are blue in the face, it won't make any difference. The original statement was that reporting an issue should not cause anyone to expect that we fix it. I said that I think that people are allowed to expect us to LOOK AT IT at least and state that we won't fix it in version N. So the process I define is: - Someone reports an issue or assigns the next version as target version to an issue And the expectation people will have from us is: - Either we fix it in the next target version OR we at least read it and assign a different target version. What currently happens: NOBODY READS THE REPORTED ISSUES, the target version stays at next version and the next version does NOT fix the issues. > > > > 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. > > You are absolutely right, if the meeting is poorly run. Perhaps you've > only ever had experience of poorly run meetings, in which case your > cynicism is understandable, but it is actually possible to keep a meeting > short, to-the-point, and avoid tangents. > > As I said, I'm not making this up, I'm suggesting this because I've done it > and I have direct experience of it working. Okay, I hereby change my opinion. It was nonsense by me to not suggest to at least try it. We can try such a meeting, but please ensure that it is properly run, at best by leading it yourself. Suggestion for a Date? I suggest that we do it in a time which fits toad, we need him at the meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101030/c01258af/attachment.pgp>
