-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
A few quick notes:
* I at least _see_ every bug, though during busy times (like
conferences) I can get behind. I also don't necessarily comment on
everything myself, so bugs that aren't getting attention may lack
feedback. :(
* Things that don't get immediate attention often do end up not being
touched again until either someone agitates or someone happens to find
it and feel like fixing it themselves.
* I'd like us to get on a standard of ensuring that all bugs new /
patches get some sort of comment within X days -- either a fix, a
rejection, or an explanation why it's going on the back burner. This
means getting some basic metrics in place, and some regular reporting of
patches falling towards the long end of the limit.
* A few times I've experimented with "bug days" grabbing folks on IRC to
find bugs of interest and either get patches made or existing patches
reviewed and committed. They've been pretty good, but we haven't quite
gotten to making them a regular thing yet. I'd definitely like to get
that going again!
* As we have more "directable" resources (more people on staff or
contracting), I'll start to have some more ability to specifically
assign certain types of bugs to people... but it's always more fun when
people take on bugs that interest them. :)
- -- brion
Brianna Laugher wrote:
Hi,
I'm interested in what is the current "bug report management" going on
with MediaWiki at the moment, and if it can be improved.
Bugzilla is purported to be the method of communication between the
Wikimedia project communities and the MW developers. But I find it
fairly unsatisfying because I feel like when I file bug
reports/feature requests, I have no confidence that they will even be
read, let alone considered as a community request, responded to,
placed in a roadmap or given a developer-POV priority. I feel like the
only I can have any guarantee of the software feature I want being
considered, is to befriend individual developers and try and convince
them about my idea. Obviously, this doesn't scale well.
<http://www.bobcongdon.net/blog/2005/11/triage.html>
Maybe it would help to try and encourage developers and techie types
to do more (or any?) bug triaging, eventually leading to individuals
or groups responsible for triaging all bugs entered within particular
Product & Component values? Extension authors are obviously
responsible for triaging their own extensions' bugs, but especially
for the Wikimedia and MediaWiki products I think this should be
helpful.
I couldn't find any mention of this kind of bug report management or
bug triaging on
mediawiki.org, so I am guessing whatever is done at
the moment is fairly ad-hoc.
It is difficult to "see" activity on bugzilla, a la Recentchanges. (I
guess if you are subscribed to wikibugs-l you see everything...) for
example there is no straightforward way (ie link from the mainpage) to
see the most recently entered bugs, or the most recently closed bugs,
or the highest priority still-open bugs. These are probably fairly
straightforward reports -- maybe it would be good to link them on the
bugzilla front page?
If activity on bugzilla was more visible, it would be easier to thank
people who spend time on bug triaging. (an otherwise extremely
thankless task!)
Another idea would be to have regular bug triage days/events, like
maybe one weekend a month, and just publicise them on here and
mediawiki.org.
I guess I would also like to know more generally, what can Wikimedia
communities do to communicate their tech priorities to y'all more
clearly? What can we do better to get clearer feedback? (Even hearing
a "no" at least gives one closure. :)) Is Bugzilla the best and only
method? Is it helpful if a community appoints a 'tech request manager'
who acts as a filter/gateway between the developers and the wiki
community?
thanks,
Brianna
[[user:pfctdayelise]]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla -
http://enigmail.mozdev.org
iEYEARECAAYFAkiWl4wACgkQwRnhpk1wk46/HQCgkT7VsOFChXNOJpwWTfhIQl/N
RkcAn2WPtOZMEfvpBEJVi9ax0GEfrUmj
=2W+4
-----END PGP SIGNATURE-----