Re: Bug tracking

My understanding was that we used the Tracker only for "action items"
that come out of meetings: E.g., bringing a certain topic to the list of so.

For spec text, I prefer using GitHub (as an editor of the SRI spec). I
tried to make sure the issue numbers in the spec match the numbers on
GitHub for those I touched recently - also explicitly saying this in the

I don't know how the "file a bug/participate" link would work.

Anne: Is this something we could get with the spec frameworks currently
in use (e.g. ReSpec)?

On 07.11.2014 14:07, Mike West wrote:
> We currently have a mix of bugs filed in GitHub and the W3C Tracker, as
> well as threads that never have bugs associated with them. I agree
> wholeheartedly that we should clean that up.
> Migrating to Bugzilla is fine with me. Doing everything on GitHub is
> fine too.
> Tracker is (IMO) not a particularly wonderful issue tracker, but it's
> integrated with IRC and the list, and there might be other
> process-related reasons to use it.
> Brad, WDYT? Would you be happy using Bugzilla rather than Tracker?
> -mike
> --
> Mike West < <>>
> Google+:, Twitter: @mikewest, Cell: +49 162 10 255 91
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
> On Fri, Nov 7, 2014 at 12:30 PM, Anne van Kesteren <
> <>> wrote:
>     I often lose track of what bugs have been addressed in this group and
>     which are still outstanding. The way we address this in the WHATWG is
>     that every specification either uses Bugzilla or GitHub in addition to
>     mailing list discussion to track important bugs. The open bugs and a
>     way of filing a new bug are clearly linked from the specification in a
>     "Participate" box at the top. There's also a script that helps you
>     filing a bug based on selection of some text.
>     Then when a bug is resolved the commit is linked from the bug, and the
>     commit itself links to the bug. This helps reviewers as they can
>     immediately see whether their bug was addressed as desired and can
>     reopen the discussion if not. Reviewers have a single point to track
>     and cannot be forgotten if a decision was made as part of a meeting
>     since their bug still needs to be resolved. This also makes it easier
>     for those trying to figure out why something changed in the past
>     (specification archeology is a popular pastime of some).
>     --

Received on Friday, 7 November 2014 13:55:10 UTC