Create 2018/Reporting bugs: getting developers to implement your feature requests: Submissions:2021/Editing seems too hard

Jump to navigation Jump to search
You do not have permission to edit this page, for the following reason:

The action you have requested is limited to users in the group: Users.


This submission is waitlisted for WikiConference North America 2018. It was not scheduled in the first round of scheduling, but may still be scheduled after further review, as slots open up, or as a pre-conference session.



Title
Reporting bugs: getting developers to implement your feature requests
Theme (optional)
Tech & Tools
Academic Peer Review option
No
Type of submission
Presentation
Author
User:Legoktm (Kunal Mehta)
E-mail address
legoktm@member.fsf.org
Wikimedia username
Legoktm
Affiliation(s) (optional)
MediaWiki project
Abstract

At the top of the Wikimedia power structure is the Technocracy. Those who control the servers and the code have ultimate powers over what happens on the Wikimedia projects. And most of the time they do a good job keeping the site up, implementing new features, fixing bugs, and so on. But sometimes, there's one issue that you keep running into, and you want someone to fix it. This talk is probably for you!

In this talk I’ll discuss different strategies to get developers to implement bugs and feature requests that bug you. I’ll talk about how to use Phabricator, mailing lists, IRC, and other community members to your advantage.

Phabricator: Wikimedia’s bug tracker can be a daunting place for newcomers who don’t understand all of the technical jargon. I’ll break down what goes into a good feature request, and how to evade the misleading “community consensus needed” label.

Mailing lists: While the wikis have moved away from mailing lists for project discussion, developers still use them as the place of record for important discussions. You can easily get the ear of most active developers, it’s important not to waste it.

I’ll go through examples of interactions that went well and resulted in features being implemented, and then some interactions that went poorly, and traps to avoid.

The goal of the talk is so that people feel comfortable approaching developers with their problems, and so that developers can work well with community members to resolve those problems.

My first experience with Wikimedia technical development was getting people to fix bugs I was running into as an administrator on the English Wikipedia. Some of my interactions went well, and others didn’t go as well. Now that I’m an active developer, I’d like to share my experience from both sides of the table and help improve everyone’s experience.

Length of presentation
20-25 min + 5-10 min Q&A
Special requests
just a projector. Note that I'm only planning to be in attendance on the 20-21.
Preferred room size
10-20?
Have you presented on this topic previously? If yes, where/when?
Nope
If you will be incorporating a slidedeck during your presentation, do you agree to upload it to Commons before your session, with a CC-BY-SA 4.0 license, including suitable attribution in the slidedeck for any images used?
Yes
Will you attend WikiConference North America if your submission is not accepted?
Most likely

Interested attendees[edit source]

If you are interested in attending this session, please sign with your username below. This will help reviewers to decide which sessions are of high interest. Sign with four tildes. (~~~~).

  1. Add your username here.


Cancel