Edinburgh Feature and Bugs Tracking

Lets brainstorm on how we can streamline bugs tracking after Dakar release. This can be done in phases.

Needs:

1. Make it possible to report on major and minor issues of TWikiRelease04x00x00, TWikiRelease04x00x01, etc
   • Include (and cache) report in KnownIssuesOfTWiki04x00x00
2. Better handling of bug Details field: Make diff work, make COMMENT possible
   • Possibly by moving Details field out of form andinto text body (and INCLUDE a header that summarized some bug form fields on top.

-- Contributors: PeterThoeny - 05 Feb 2006

Discussion

I suggest to approach this in phases. Phase 1 is a "low hanging fruit" phase that addresses urgent needs. Please add your items to above list.

-- PeterThoeny - 05 Feb 2006

1. The difference between the support web and the bugs web must be made clearer for end users.
2. There has to be a way for "Engine" to be associated with a specific TWiki version more clearly. Bugs against the DEVELOP branch are not necessarily against the release. Or is this what you meant by (1) above?

-- CrawfordCurrie - 20 Feb 2006

Is the plan now for all bug tracking to be done in the develop.twiki.org Bugs web and not in Codev?

-- SamHasler - 17 Apr 2006

That's how all 4.0 or later bugs and enhancements are currently being tracked.

-- MeredithLesly - 17 Apr 2006

Sam. In my view the Bugs web (which is still TWiki = good) is a huge success. It can probably still be improved but overall it is really a success. And the integration with SVN and the way we use it to autogenerate part of the release note is a great enhancement. What we need to do is ensure that the develop server and the twiko.org server better share user accounts (near instant update on develop when people register on twiki.org).

And naturally ensure that bugs still open on twiki.org and either discarded or moved and that the pages for entering new bugs are changed to simply point to Bugs.

On a follow up to Peter's note on moving details out of form. Steffen has worked hard on getting the CompareRevisionsAddOn to work. It shows changed much better than rdiff. But like rdiff it works badly on form fields (only shows the entire field has changed) which is the reason why Peter proposed to move text our of form. If we could ask.., no encourage..., no beg on our knees that the add-on was enhanced to also handle form fields - this would be perfect for Bugs. And for many others. Steffen ;-)?

Finally - on the note about showing known issues on the KnownIssuesOfTWiki04x00x00 this is a great idea. One problem is that to the admin user knowing that a bug is resolved in SVN 9787 is of no use. To be useful for the user you have to be able to download a patch - or a copy of the files containing the fix - or a text description what to alter to fix the problem.

-- KennethLavrsen - 17 Apr 2006

That's pretty much the impression I had gained; that the bugs web had become the de facto place for tracking all changes.

However, the problem I have with the bugs web is that whilst those who are most active in development find it convinient it is less visable and hard to dip into for those who aren't. That's in part because it's not on twiki.org so I can't monitor changes from WebChangesForAllWebs, and partly because of the obsure ItemXXX naming convention.

-- SamHasler - 18 Apr 2006

I agree with Sam. Admins will go to Suppor for support, and will check the KnownIssues topics and support to verify if somebody has the same issue as them.

OTOH, the Bugs web is a very convenient place for developers to track what's happening and to really control each release.

So, a compromise should be found.

There is a model that is effective but imply additional work for those that keep an eye on Support:

• Direct all users and Admins to the Support web and the KnownIssues topics. Encourage them to look for similar problems there or to create Support topics with their problem.
• People keeping an eye on Support create the proper report in the Bugs web, and put a link to the created item in the Support topic for future status tracking.

That way we have the best of both worlds, with some compromises.

-- RafaelAlvarez - 18 Apr 2006

I wasn't even considering how it relates to support or admins looking for issues. I'm thinking more of the casual contributor who contributes to the brainstorming topics in Codev and would like to know what's going on development wise with topics they are interested in.

As it is there is much development that happens solely on the Bugs web that is not visable to those that are only tracking Codev / WebChangesForAllWebs.

-- SamHasler - 18 Apr 2006

renamed from PostDakarBugsTracking to PostDakarTrackingAndDiscussion because there are two inter-related issues we need to discuss here.

We need to not only consider how tracking is to be done, but also how discussion is going to feed ideas into each release.

-- SamHasler - 29 Apr 2006

My intent is that this topic should also encompass the issues of BackToCodev and CleaningUpCodevRevisited ManageStaleContent etc. as how we want to manage tracking and feature discussion in future can have an impact on how we organise content in Codev and manage content on twiki.org.

-- SamHasler - 01 May 2006

Modify ChangeProposal for new TWiki Release 4.1 Process

It is my understanding that this is related to TWikiRelease04x01Process. Sam is going to revise the ChangeProposals to support the new process on twiki.org, as discussed in EdinburghReleaseMeeting2006x09x04.

Related, the bug tracking in the Bugs:WebHome web can be improved:

• Move description field to main topic text (so that diff works)
• Add header to item topics that shows summary of most important form fields

-- PeterThoeny - 24 Sep 2006

I've already modified ChangeProposalForm so that it now has a BugTracking field. See EdinburghReleaseMeeting2006x09x04 and it's IRC log for details. That was fairly straightforward and I didn't think there was going to be much impact on picking one name over another so I implemented it straight away.

There is a requirement for an "owner" field for the form but there were a couple of different suggestions for what it should be called and issues of how it's naming will affect it's use, so I'd like to have some discussion about it before it is implemented.

There was also some discussion of an "UnderReview" state that I'm not sure was fully resolved.

Below is a summary of the relevent IRC discussion from EdinburghReleaseMeeting2006x09x04

I've marked the lines that are most relevant and left the rest in for context/completeness.

Key:

• o - "owner" field
• r - "UnderReview" state

I've also left the BugTracking discussion at the end for reference.

   Lavr         A problem with the current implementation is that it works as a 
                wish list for users. You can wish all you want but nothing is 
                done unless someone is committed to do it.
   PeterThoeny  good point
   Lavr         The issue we address are the requests where someone IS committed 
                to do it - but needs approval from the community.
   PeterThoeny  that possibly can be addressed by a state?
o  Lavr         Could be. The form must contain a status that says that the 
                feature implementation has an owner that has committed to do it. 
                And the name of the owner.
   Flenser      wishlists should be confinded to BasicForm+BrainstormingIdea
   PeterThoeny  lets see if we can compile the requirements
o  PeterThoeny  - way to track owner (make committment visible)
o  Flenser      we got rid of that the last time we revised the form
   Lavr         And we need a field the "customer advocate" can set so you can 
                make a search for topics that needs discussed at release 
                meeting. Can be a state also
   PeterThoeny  - track "concerns": raise, investigate, resolved
   PeterThoeny  lets divert a bit: the bugs web works nicely, i think due to its 
                simplicity
   Flenser      should that be confined to ChangeProposals? you could have 
                BasicForm topics with classifications of TWikiDevDoc, 
                TWikiDevQuestion that you might also want to raise
   PeterThoeny  i think if we simplify the change proposal tracking we get a 
                good acceptance
   Lavr         Yes. Simplifying. And we need to decide what to do with the 258 
                proposals already there that are rotting. It is not realistic to 
                think anyone will run through them in any near future.
   HaraldJoerg  Lavr: Correct. That's the problem I have with discussing the 
                process.
   PeterThoeny  on existing proposals: this can be solved with a 
                reclassification to new "parked" or existing "needs rethink"
o  HaraldJoerg  Flenser: You wrote that the "owner" field has been removed from 
                the form. What was the reason?
   PeterThoeny  easy to do with global search & repalce
   PeterThoeny  those who wish to pick up a feature can reclassify it
o  HaraldJoerg  I would prefer to discuss only proposals which do have an owner, 
                and mark all the rest as "parked"
   Lavr         Could be. I just want to make sure that it is easy for Steffen 
                and I to only see the proposals that have a committed developers 
                that wants acceptance to go ahead.
o  Flenser      HaraldJoerg: one of the reasons the owner field was removed was 
                that it was felt it was a barrier to others stepping in and 
                helping
   HaraldJoerg  I think that has backfired
o  PeterThoeny  i think an owner reflects commitment
o  HaraldJoerg  IMHO others are more likely to step in if they know whether or 
                not they are stepping on one's turf
o  HaraldJoerg  ...or to see that they can help with a small contribution 
                without having to carry the whole load of a topic
o  PeterThoeny  and people are more likely to add notes if they see a chance of 
                making it into an implemented feature
o  Soronthar    Call it "Champion", not "Owner".
o  PeterThoeny  or "committer"?
o  Soronthar    Yes. That. Something that reflects that "He's the one doing the 
                work"
o  Soronthar    not "this is HIS feature"
   PeterThoeny  yes, good point
o  Flenser      does commiter imply that they make all the svn commits?
o  HaraldJoerg  I'd also allow someone to be the owner if he's the one to 
                motivate others to code stuff
o  HaraldJoerg  Well written requirements can give "ownership" of a proposal 
                without needing to code
  
   PeterThoeny  any other requirements for change proposal changes?
   PeterThoeny  yes, in regards to new process
   Lavr         Remember also that the old process also was used for small fixes 
                for which Bugs is used now. The Codev twiki app is for new 
                features, spec changes, and similar. The things that require a 
                community decision (which can be silence = accepted). An 
                uncommitted feature request from a user does not get accepted 
                from being ignored. It will not be picked up by the "customer 
                advocate" role unless someone says "I will do it".
 r Soronthar    we need an "UnderReview" state
   Flenser      what does that imply?
 r Soronthar    that is under review for fitness
   PeterThoeny  actually, someone can bring a proposal and wait for two weeks if 
                there are any concerns
   PeterThoeny  that is one state
   PeterThoeny  if someone raises a concern, that is another state
 r HaraldJoerg  UnderReview is UnderInvestigation, isn't it?
   PeterThoeny  if no concern, it is accepeted after the grace period
 r PeterThoeny  that is the third state
 r Soronthar    I don't see it like that.
 r Flenser      how would it fit into the UnderInvestigation -> ConsensusReached 
                -> UnderConstruction workflow? see the ChangeProposal topic for 
                definitions
 r Soronthar    because I expect that if I have a fully-formed patch ready for 
                merge, the feature is not "under investigation
 r Soronthar    UnderInvestigation -> ConsensusReached -> UnderConstruction -> 
                UnderReview->ReadyForMerge
 r Lavr         Once the proposal is accepted - there is no need for more 
                states. Work continues on Bugs.
   Soronthar    the latest sample was the =configure= rewrite from CDot and the 
                FnTags from Meredith. They where "built" and "Reviews"
 r HaraldJoerg  Soronthar: I'd prefer to do as much review as possible *before* 
                the patch is done.
 r Flenser      I think the ReadyForMerge state is the review state
 r Soronthar    review of the "spec" and the idea, yes. I agree on that
 r Lavr         The idea is that people can get an acceptance of the feature 
                BEFORE spending time coding the feature.
   PeterThoeny  yes
 r HaraldJoerg  I'd like to get pointed to e.g. changes in TWiki behaviour by 
                the Codev topic, and not by wading through the code, or by beta 
                testing
 r PeterThoeny  actually, both happens: code ready or not ready at the time a 
                proposal is done
 r PeterThoeny  possibly decouple state of code readiness and handling concerns?
or Lavr         I see two sources of these Feature Proposal topics. User that 
                makes a wish, or developer that wants to add a feature. And I am 
                afraid we drown is the former. There are more wishes than 
                resources to do them.
or PeterThoeny  what i would like to see is a report that shows all pending 
                change proposals for edinburgh, with an indication of the 
                concerns
or Lavr         in the former.
 r Flenser      if there are concerns then code readyness is irrelevant, just 
                track the spec/concerns, not the code
o  PeterThoeny  kenneth: wishes and commited change proposals can be 
                distinguished by the committer field
o  Lavr         Yes. It just needs to be clear that the person that submits the 
                proposal should not fill out this committer field. And the word 
                "committer" may not be very clear on this.
 r Soronthar    hmm.. we're talking different things: you're talking more about 
                "consensun on the IDEA" status, and I was talking about "The 
                code can go into SVN" status. My mistake. I agree with the 
                workflow for the status of the idea.
   Lavr         Yes. If we start reviewing code before committing it to SVN we 
                drown the developers in red tape. A bad commit can and will be 
                reverted. SVN makes that easy so no danger anyone screws up 
                everything.
   PeterThoeny  another idea: add a BugsTracking field
o  PeterThoeny  if empty, it means no committer, e.g. wish
   PeterThoeny  if bugs item is listed it means it is tracked
   Flenser      PeterThoeny: do you mean a field for listing releated bugs?
   Lavr         You would not open a Bugs item before the proposal is accepted 
                in my view.
   HaraldJoerg  The bugs item bears the danger that a topic is discussed in both 
                bugs and Codev webs
   Flenser      actually it makes it less likely
   PeterThoeny  a change proposal needs to be tracked in one or more bugs items 
                once the svn work starts
   Flenser      because you can more easily see the bugs topics so you can 
                comment on them
   HaraldJoerg  Flenser: I've made a different experience with Item2582 vs. 
                OrganizeTWikiVariables
   Lavr         A reference to Bugs is a good idea. Many proposals rise from a 
                bugs item so the reference is good. But we cannot use the Bugs 
                field to determine if a developer is driving it.
   PeterThoeny  harald: this can be addressed by adding links both in directions
   PeterThoeny  "adding links in both directions"
   HaraldJoerg  That topic had links in both directions.
   Flenser      not in a location where people were used to looking
   HaraldJoerg  The weakness we currently have in the process is that discussion 
                doesn't start in Codev before a SVN commit is done
   PeterThoeny  that point is addressed by the new process

We need to decide what to call the "owner" field. There have been three suggestions so far owner, champion and commiter. We need to decide on one name that fulfils the following criteria:

• Does not imply they will be doing all the work (someone can be the owner if they're the one motivating others to code stuff)
• Reflects commitment / does not imply they won't be doing any work
• Fulfils all of the above as unambiguously as possible
• Is a WikiWord

Keep that last requirement in mind when making suggestions.

This might be a bad idea but I'll throw out a few more suggestions:

• owner
• committer
• champion
• driver
• chaperon
• conductor
• pilot
• superintendent
• curator
• custodian
• overseer
• supervisor
• shepherd
• babysitter
• mid wife

(yes I used a thesaurus for a couple of those)

These aren't all nesessarily all appropriate but I wanted to bring out some of the qualities of the kind of work we're looking for (e.g. mid-wife brings out "Does not imply they will be doing all the work" rather well and also emphasizes how hard it can be to see a proposal through to completion )

What suggestions do you prefer? Do you have a beter name for the field? How do we make it a WikiWord?

-- SamHasler - 10 Oct 2006

I'm missing supervisor. They drive a project not necessarily doing the work. Or what about spearhead -- hm, does sound too militant, doesn't it?

-- FranzJosefSilli - 11 Oct 2006

Ok, I've added supervisor to the list. I know I saw it when I was putting the list together, I can't think why I didn't include it. It's been a week, I'd have hoped to have generated more feedback by now. I think I may just take a straw poll at the next irc meeting and we take whatever is most popular for whoever turns up to that meeting.

-- SamHasler - 19 Oct 2006

Here is a short summary of what I think we need to do to automate the new TWikiRelease04x01Process. This is mainly based on the manual tracking Kenneth is doing in WhatIsIn04x01:

• State tracking:
  • Proposed - a proposal which does not yet have a driver willing to get it implemented.
  • Committed Proposal start of two weeks review period with auto acceptance of no concerns are raised.
  • Accepted - green light, no major concerns encountered/remaining within two week review period.
  • Parked - deferred to later release, or pending owner action. But will most likely be accepted when driven by owner.
  • Not accepted - can be done as an extension.
  • Deliberate - discussion still ongoing on proposal topic. Not ready for release meeting decision.
  • Decide - ready for decision at next release meeting.
  • Done - feature is accepted and done.
• Time tracking: We need a start date, and based on that a visual indication in the reports to distinguish Proposed/Accepted.
• Reports: Easy way to see items that:
  • need to be discussed at release meeting
  • are proposed and open for deliberation
  • all accepted and done items for each release

-- PeterThoeny - 13 Nov 2006

This poor man's version of ClearQuest or Bugzilla could be easily implemented using WorkflowPlugin. You can even define a state machine of legal transitions between those states.

-- ThomasWeigert - 14 Nov 2006

On Peter's summary. We need one important thing tracked.

There are two types of proposals.

• Those that users propose without having anyone committed to implement them. Surely no 14 day rule applies to these.
• A named developer has given the commitment to drive the proposal. This is where the 14 day rule starts. The 14 day rule is there to ensure that no developer with a will to implement something has to wait and beg for feedback. This was a strong wish from the development community and the reason why we have the rule.

The 4.1 process did not have the same problem because only the regular developers knew about the almost secret WhatIsIn04x01 so all proposals there except a few had a committed driver.

I marked the missing state in RED. An alternative approach can be to have a field with the name of the committed driver. And only when a name is added do we start the 14 day clock. That saves the committed state and makes it possible to change state to 'Not accepted' if someone suggest something which we can reject right away (RTFM type proposals for example) without assuming later that there was a driver for it.

I do not think we need a state machine. That is just an extra pain in the butt if we limit how to go from state to state. Just like ClearQuest is by the way! I like the soft security principle of TWiki. And in practical life we can jump from any state to any state. On Bugs web we have never needed any strong workflow rules either. I can open a new bug item in Actioning state.

-- KennethLavrsen - 14 Nov 2006