Proposed changes to workflow bug management

[Emmet Hikory]

Scott Kitterman wrote:
> Agreed.  I think "Don't mark on bugs you don't understand" is a much more
> useful approach than setting rules on which classes of people can touch
> which kinds of bugs.

    Just to be fair, and in reference to some of the discussions that
were partly responsible for initiating these threads, this ought have
a corresponding "educate rather than complain" for those cases where
bugs are handled in a non-ideal manner.  While we've been discussing
primarily workflow bugs, the same can also be seen in other cases
where people less familiar with our various launchpad processes (for
any team) may make an incorrect adjustment.

    In addition, I think it is important to define "understand" to be
about the type of bug, and how it relates to the package.  I don't
believe it is necessary to understand the specific issue that causes
the bug in order to start working on it (especially so for those who
are not also developers), although I can see value with this rule
where it is more general: compiled code often benefits from a
stacktrace, interpreted code often benefits from a backtrace, display
or sound issues often benefit from certain files, etc.  All of these
may be crashes, but the information required to accurately determine
the problem differs.  Similar guidelines apply to any class of bugs
(workflow, crashes, typos, unexpected behaviour, feature requests,
etc.).  Similarly, different groups of packages are handled
differently, so for example GNOME bugs are usually pushed upstream,
Games bugs are usually pushed to the Debian Games team,
Install/Upgrade bugs are often fixed directly in Ubuntu, and these
differences are also in the repetoire of things worth learning, and
things worth educating others about.

-- 
Emmet HIKORY