Mailing List Archive

“Easy” Bug Triage meeting notes
This past Wednesday, we had our second IRC triage. The focus was on
triaging bugs marked “easy”, verifying that they were still bugs and
making sure they were actually something a new coder could do.

This meant we had a larger number of bugs to cover. I had planned
only 2 minutes per bug in order to get through all of them in an hour
which caused problems. This short time limit created some problems
which means I'll have to be careful to restrict the number of bugs in
the future, or tell people the time for the triage will be longer than
one hour.

Still, despite the problems, hosting the triage in IRC meant that some
developers interested in MediaWiki that Sumana invited were able to
watch and volunteer developers were able able to participate.

Before talking about the ones that are already done or that we decided
were not something a new developer should attempt, I'll give you the
list of bugs that we confirmed as “easy”:

http://bugzilla.wikimedia.org/25909 Add a drop-down list for the tags
in RecentChanges and NewPages

http://bugzilla.wikimedia.org/26470 Add toggle for checkered or
transparent image background on file description pages

http://bugzilla.wikimedia.org/28162 Installer does not respect initial
DBport declaration

http://bugzilla.wikimedia.org/28173 Postgres defaults to a unix
socket - mention in install?

http://bugzilla.wikimedia.org/28296 Installer should honor &uselang=
parameter

http://bugzilla.wikimedia.org/28981 handle diffonly param on diffs
between deleted revision

http://bugzilla.wikimedia.org/29110 $wgFeedDiffCutoff doesn't affect
new pages

http://bugzilla.wikimedia.org/29311 [OutputPage] Create a method to
remove items from mModules

http://bugzilla.wikimedia.org/19295 Navigation headings should not be
lower-cased in German (and other languages)

http://bugzilla.wikimedia.org/8178 [low enhancement] Make table of
contents for category pages: Subcategories, Pages, Media

http://bugzilla.wikimedia.org/21511 Document all configuration
variables (usable in LocalSettings.php)



By walking through bugs in this way, we were able to close a few
right away as invalid or already fixed:

http://bugzilla.wikimedia.org/23442 javascript error in examine mode

http://bugzilla.wikimedia.org/27394 Message "lastmodifieddat" should
be in user language instead of for content

http://bugzilla.wikimedia.org/27047 Nicer design for pre elements in
Vector

http://bugzilla.wikimedia.org/25839 Add class for block ending time
<span> element

http://bugzilla.wikimedia.org/22770 wrap rights on
GlobalGroupPermissions into a CSS class

(Had a patch that looked usable, but yesterday, after the triage,
DieBuche pointed out that creating a new CSS class wasn't
necessary.)

These next ones had patches that needed to be to be reviewed and
applied:

http://bugzilla.wikimedia.org/28838 Remove redundant IE-CSSFix rules
from monobook/main.css

Applied in r91742

http://bugzilla.wikimedia.org/28147
MediaWiki:Centralauth-login-global - rewording suggested to make
it more concrete.

Applied in r91706, fixed up by SPQRobin in r91733.

http://bugzilla.wikimedia.org/27894 Move edit on double-click event
listener down to div#bodyContent

Brion and Krinkle have been reviewing the patch but since the
original submitter hasn't replied for 2 months (despite other
recent activity on the bug), this is a good place for another
developer to jump in and take over the work.

Of course, when you're looking over “easy” bugs, some of them get
fixed soon after:

http://bugzilla.wikimedia.org/23086 [extensions] AbuseFilter config
diff date and time should use user preference instead of UTC

SPQRobin fixed in r91619

And then there were the ones that were marked “easy” but, after
discussion, really weren't:

http://bugzilla.wikimedia.org/13862 Add a horizontal table of contents
to Special:SpecialPages

http://bugzilla.wikimedia.org/20781 Move 'mainpagetext' message to
installer's .i18n file once it exists

(Yes, this is easy, Except that it needs coordination with
Translatewiki.net. If we could move all of the MessagesXX
translations to Installer.i18n.php in one move, it wouldn't cause
any headaches for translators.)

http://bugzilla.wikimedia.org/24159 Remove uses of the error
suppression operator

(Most of the low hanging fruit has been done here. The ones
remaining can be a bit remaining can be a bit tricky.)

http://bugzilla.wikimedia.org/27501 List categories from foreign file
repositories on the File description page

(Need to rewrite the way the description page is fetched from the
foreign repo. Can be done via the API.)

http://bugzilla.wikimedia.org/27545 Extension:reCAPTCHA has badly
worded message

http://bugzilla.wikimedia.org/12532 File links on image description
page should be in alphanumeric (alphabetic) order

(Could be easy, but requires one to make sure you don't do
something stupid with the db query. A-Z Sorting all linked pages
is slow/unindexed, sorting only the first (random) 200 entries is
confusing for the user.)

http://bugzilla.wikimedia.org/29290 continue does not work in same
cases for prop=iwlinks&iwcontinue and list=iwbacklinks&iwblcontinue

http://bugzilla.wikimedia.org/26597 Allow toggling of persistent
cookies ("remember me") in API action=login

(Sam's initial fix was reverted, so maybe not so easy.)


Thanks, everyone, for helping out!

Mark.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: “Easy” Bug Triage meeting notes [ In reply to ]
On 07/08/2011 02:20 PM, Mark A. Hershberger wrote:
> This past Wednesday, we had our second IRC triage. The focus was on
> triaging bugs marked “easy”, verifying that they were still bugs and
> making sure they were actually something a new coder could do.
>
> This meant we had a larger number of bugs to cover. I had planned
> only 2 minutes per bug in order to get through all of them in an hour
> which caused problems. This short time limit created some problems
> which means I'll have to be careful to restrict the number of bugs in
> the future, or tell people the time for the triage will be longer than
> one hour.
>
> Still, despite the problems, hosting the triage in IRC meant that some
> developers interested in MediaWiki that Sumana invited were able to
> watch and volunteer developers were able able to participate.

Mark: Thanks, as always, for running this triage. I have now added the
relevant bugs to

http://www.mediawiki.org/wiki/Annoying_Little_Bug

which you should feel free to hand out to developers interested in
writing their first MediaWiki patch.

--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: ³Easy² Bug Triage meeting notes [ In reply to ]
Sumana Harihareswara wrote:
> On 07/08/2011 02:20 PM, Mark A. Hershberger wrote:
>> Still, despite the problems, hosting the triage in IRC meant that some
>> developers interested in MediaWiki that Sumana invited were able to
>> watch and volunteer developers were able able to participate.
>
> Mark: Thanks, as always, for running this triage. I have now added the
> relevant bugs to
>
> http://www.mediawiki.org/wiki/Annoying_Little_Bug
>
> which you should feel free to hand out to developers interested in
> writing their first MediaWiki patch.

I sporadically made a complementary page (without references) at
<http://www.mediawiki.org/wiki/Annoying_large_bugs> which lists more complex
(and more exciting) bugs.

The "easy" bugs list is nice, but it doesn't really spark much creative
energy. A second page with more exciting (but harder to implement) bugs
seemed appropriate. :-)

I tried to list bugs that a lot of users are more likely to encounter, both
on Wikimedia wikis and on their personal MediaWiki installs.

MZMcBride



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l