Readers/Web/Working with us

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

Working with engineering
The reading web team is small, yet 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, 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. 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.

Requesting code review
If you need time from the web team for either code review, engineering effort or design input, please request this formally on Phabricator by pinging our product manager and tagging the task with #kanbanana (if a patch exists) or #readers-web-backlog for future work. If support from the web team is expected for multiple efforts e.g. multiple tasks, please reach out via e-mail to check the web team's capacity for code review.

The more in advance you let us know of your need, the more likely we'll be able to fulfill it.