#979 Features process proposal: Track features in bugzilla
Closed None Opened 11 years ago by mattdm.

= phenomenon =

Currently, wiki pages are used to track the progress of Fedora features. This has a number of problems:

  • meaningless percent-complete indicators
  • lack of consistency both in format and meaning
  • difficult to review everything in one place
  • next to impossible to automatically produce statistics

= recommendation =

Continue to use the wiki as an overview of the feature itself, but progress towards completion should be tracked in an issue tracker. This could be done in a separate (new) trac instance, but I think it's preferable to use bugzilla, because most actual feature work will be in the form of package updates.

  • Create a new bugzilla component named "Fedora Feature".
  • For each feature, create a tracking bug (template for this bug would include a link back to the wiki page for details; the idea wouldn't be to describe the whole feature in bugzilla)
  • Specific work to implement the feature would be other bugzilla tickets marked as blocking that tracking bug
  • These specific bugs could be as granular or as broad as the feature team wishes
  • We could write something to produce [http://en.wikipedia.org/wiki/Burn_down_chart burndown charts] as the feature progresses, and ideally embed them back in the wiki

A few points:
1. Having good bugzilla tooling would certainly be welcome - in particular, burndown charts for tracker bugs would be useful independent of the feature process.
1. The tooling is still only useful if it is used in a compatible way (e.g. time estimates attached to each bug, or all bugs of comparable size). There is a very real risk of getting ''less'' useful data than we have now - "8/10 bugs done" is less useful than verbal status like "my feature is at 75%, however I can without any risk drop the remaining 25% if they are not done on time".
1. For feature owners that already use bugzilla for tracking the progress, this would be free (see 1.); however for feature owners that work "upstream", we either get useless information again (a single bug that says "import upstream package when ready"), or we impose ''additional'' bureaucracy of maintaining a parallel bug tracking schema here. Arguably package maintainers should be tracking Fedora-relevant items in the Fedora bugzilla, however having two systems in parallel is a major pain so I'm not sure how strongly we'd want to require this.

Good points on the caveats.

On the sizing issue, it's okay if not all different features use comparable sizing — it just has to be consistent within each feature. If you have enough entries, the size averages out and doesn't matter too much; alternately, we could enable (or use the whiteboard for) sizing features. Also, bugs which don't affect the deadline could be removed from the tracker.

For the issue of projects which also use a different tracking system: maybe we should mandate it for critical path changes, but make it optional for leaf features? Feature teams could also make milestone-tracking bugs in bugzilla and not track every issue there.

I wouldn't make bugzilla trackers mandatory. Even the graph might be seen as more bureaucracy and people would be less inclined to create proper feature page. I agree the percentage is not very helpful. I would be fine with states of feature - red (panic, can't make it), yellow (warning - blocked on something), green (doing fine, no worries).

My features were usually about rebuild of Perl related packages. We created bugs only for bugfixes, which weren't easy to do (as classical FTBFS) and if they were fixed or not, wasn't a blocker for a feature. I agree proper tracker bug in some cases would be useful (sysv init script -> systemd units).

Deferred until a broader discussion of the Feature process is held.

We have revamped things some after fudcon, shall we discuss this proposal again?

I can't attend today, but I'm fine with proposal, which was prepared during our personal meeting on Developer Conference.

Replying to [comment:8 mmaslano]:

I can't attend today, but I'm fine with proposal, which was prepared during our personal meeting on Developer Conference.

Any link to such proposal?

My point on this - we definitely need a better way for the tracking, at least I need such - wiki is wiki - I have set of scripts, currently broken (so the FeatureList is actually outdated right now, sorry, I have to fix it) but still it's not very optimal. But I'm not sure BZ would suit the needs better - it's not a project tracking tool. When we use it for anything except reporting bugs, we end up with a huge mess of keywords, workarounding it (see blockers...). On the other hand I understand the value of being able to block depending bugs on the bug for the feature. So it could be useful for example for tracking package reviews for missing packages etc., or bugs that has to be fixed. But not for all features. So I'd be more for Trac, even it's still not a huge win here but it's still possible to model the process there better (and link wiki for change proposal, link BZ for tracker bug etc.).

I don't think we need need to have a "huge mess of keywords" -- I think it can be accomplished pretty nicely with just tracker bugs.

Maybe it's just me, but I find trac rather of awkward to use, and bugzilla has the advantage that actual work bugs can be marked as blockers, keeping everything in one place. This is particularly nice as both package reviews and work on actual packages already use bugzilla, so there's no cost to hooking those things all together.

Trac would be better than than nothing, though.

agreed FESCo is ok to go with whichever tracker the program manager would like

Ok,
I was thinking more about it and talked with a few people around - I'm in favour of this proposal, if we split 1) the submission/approval process and then 2) tracking process (maybe I misunderstood proposal in the beginning to accomplish 1 in Bugzilla too).

So for every feature/change (for at least now still managed as wiki page - adding Trac to the mix would make it even more complicated than needed) accepted (implicitly/explicitly) by FESCo, create bug in Bugzilla (I'd say 'distribution' component should be ok - no need for a different one). Then Feature/change page will be linked to the bug, to keep it in sync, script will be created. I'm more for Bugzilla in this case as developers know it, as Matt pointed out - bugs could block tracking bug etc.

Login to comment on this ticket.

Metadata