dan_the_man at telus
Aug 4, 2008, 4:23 AM
Post #6 of 17
(783 views)
Permalink
|
|
Re: Bug triaging; community -> dev communication
[In reply to]
|
|
^_^ If you have a list of potential "directable" resources, put me on there.
There are plenty of longstanding bug reports or features in bugzilla
which I do have an interest in, and an idea on how to fix.
I just can't get around to any of them, because those need a fair bit of
focus, and right now I can only focus on something if it gives me a good
portfolio item (MediaWiki extensions and code changes don't cut it in
that area, I need a system with a UI that was discernibly made by me),
or pays.
I honestly don't know about the Triaging of bugs. As I see it MediaWiki
is quite more open and free form than other projects I see. We have few
general groups of people who would be compelled to triage a large list
of bugs. Rather people take a category of bugs they are good with (UI,
Special pages, extension features, API, etc...) and they grab some they
are interested in and fix them.
The "release cycle" MediaWiki uses also differs a fair bit. We're not on
a planned schedule of "these features are what we want to see by the
next release", people just come up with improvements and add them into
the software.
Though, perhaps a better way of visualizing the bugs we have would be
good. We have some generic categories in bugzilla, but I don't see fine
enough categories or tags which can help attract people to bugs on
things they are interested in. Actually, the notion of trying to search
bugzilla for 'features', or 'issues to fix' is a bit of a mess.
What would be interesting would be a real 'feature tracker', rather then
a mess of bugzilla reports, an actual categorized, and tagged list of
features people would like to see in the software. Something with more
control and organization than bug reports. Even a tag cloud with a
variety of free-form categories would help to track down bugs/features
one could work on.
((Perhaps sidetracking by now...))
Actually, COfundOS <http://www.cofundos.org/> has an interesting
concept. While I'm not a fan of the method there for selecting who would
do something, it is an interesting concept. Especially if it were made
more open and simply integrated with feature tracking, rather than
focusing on the payment.
* Put the features out in a list.
* Comment on what the feature needs.
* If people are highly interested in the outcome of a feature, they can
throw in a buck or two.
* Someone interested in working on the feature can claim it and start
working.
** If someone else is interested they could claim as well.
** The claiming developers can discuss the task, see if they want to
share the work, have one abdicate the claim and let the other work, or
build and see who has the better outcome.
* When the feature is completed the task is resolved, and if anyone
chipped in for the feature it gets sent to the dev(s).
It would work whether anyone chipped in for the feature or not. And if
people did chip in, the dev would get some spare change as thanks for
doing something they may have been interested in working on themselves.
Wiki work breeds wiki? How many devs have their own hosting for running
MediaWiki, even if it's only testing?
<https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=transwiki&product=MediaWiki&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=>
~Daniel Friesen(Dantman, Nadir-Seen-Fire) of:
-The Nadir-Point Group (http://nadir-point.com)
--It's Wiki-Tools subgroup (http://wiki-tools.com)
--The ElectronicMe project (http://electronic-me.org)
--Games-G.P.S. (http://ggps.org)
-And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
--Animepedia (http://anime.wikia.com)
--Narutopedia (http://naruto.wikia.com)
Brion Vibber wrote:
> -----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-----
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|
signature.asc
