Readers/Web/Working with us

A few notes about how best to work with the Web team.

Working with Web team engineering

Before submitting code

As staff

If you are submitting a patch to our codebases and requesting code review, please create a Phabricator ticket before doing so. If you need or will need code review from the team please explicitly tag #readers-web-backlog and ask for it on the task.

In the rare situation you want to write a patch that does not need our review and/or doesn't need a Phabricator ticket, please comment explicitly on the Gerrit patch about why. This saves us a lot of time in wondering about what to do with it.

If you need time from the web team for a substantial amount of engineering effort or design input, please request this formally on Phabricator via a task tagged #Epic and ping our product manager. Please reach out via e-mail to check the web team's capacity for code review for large efforts. The more in advance you let us know of your need, the more likely we'll be able to fulfill it.

For more details, please see: Request process

As a volunteer

The Web team maintain a large amount of extensions and skins. While we appreciate and have capacity to review patches that fix bugs, we are very selective in taking on new endeavors.

If you are interested in our projects, we recommend new volunteers and team members start with bug fixes to become familiar with the code review process, and the team. Possible tasks have been identified with the #good-first-bug task. While this may not be the exact thing you want to work on, it helps us set expectations around code review time and help us get to know you. We also would appreciate an introduction, either on the mobile-l mailing list or the IRC channel #wikimedia-mobile ^connect, but this is not required! It will definitely help to have an asynchronous communication channel with you to discuss changes.

Submitting code

Before submitting code to us, please note:

• Our code-bases contain a lot of hidden complexity. Things that look like easy fixes, are often not.
• Your priorities do not necessarily match the teams. Always be transparent about what you have planned and respectful of the time of code reviewers. Code review is often more time consuming than actually writing the code.
• If you are planning a large amount of contributions, please only submit patches if you have identified a code reviewer beforehand to avoid feeling like your contributions are not welcomed.
• Raise Phabricator tasks first for newly proposed work
• Check in on existing tasks whether patches would be helpful and whether somebody would be able to review them.
• There are other ways to help us that don't involve submitting code to our code bases. Efforts to improve documentation, communicate changes to editors and prototype are highly valued

During the review process please:

• Read and respect the code of conduct
• Bear in mind that code review can be slow, particularly for changes that touch large and old parts of the code base and/or that are out of scope for our current short term commitments.
• If a patch exists on one of repos, we are likely to know about it. If we are unable to review it, we will let you know on the associated Phabricator ticket. If you have not heard back in any form after a week of a submission, you should feel free to request feedback on the associated Phabricator task, however please do not send daily reminder comments on Gerrit or Phabricator.
• Respect decisions made by the maintainers during code review even if you disagree with them. We value discourse, but it must be carried out in a civil and respectful manner. At the end of the day, if there is any problems with the code, the maintainers are the ones that need to react to it.

Working with Web team design

No information at current time.

Working with Web team product

No information at current time.