Announcing an all new Papercuts Ninja team.
We already have teams for bug triage, teams focused on packaging, teams for reviewing old patches, team for sponsoring patches, teams for each package, teams with just a bunch of other teams in them…
So, why are we forming a new team? Who is this team for? Why should you be excited?
We want to make it easier for people to fix papercut bugs. Have you been already working on papercut bugs, but don’t want to go through the hassle of wading through the list of accepted papercuts or had trouble trying to find a bug you’re interested in? Just subscribe to the mailing list and get notified when a new papercut bug is accepted.When you notice one you like, claim the bug, assign it to yourself and just fix it! 🙂
We also want to make it easier for new members to start working on Ubuntu. When a new member is interested in helping Ubuntu, they would like to help fix bugs in Ubuntu but are often lost.They do not dissociate Ubuntu from Upstream packages or projects. They just want to help Ubuntu and fix bugs. As a new member interested in fixing bugs in Ubuntu, where do they ask? Where do they start?
After looking around for a while, some have been successful in finding a bug they are interested in fixing and they submit patches in Launchpad. But, Launchpad might turn out to be the wrong place to submit the patch! The project may not be hosted in Launchpad, there is no response from the developers and the patch is left uncared for. We end up having a huge list of patches which have not been touched for ages, we form a team of reviewers and try to cleansweep the patches to the appropriate place. Can we try to prevent this better?
Passing all these hurdles, some members write a patch and submit them at the appropriate place. But they are not sure if the patch is good or if it is the right way to go about fixing the bug. Upstream bug-trackers are riddled with patches which need a lot more work before they can be committed into the main branches. The patch undergoes several reviews from an upstream developer, revisions from the submitter and then finally the patch is good. During this review-revision process there is only a direct one-on-one interaction with the new member and the upstream developer has to repeat the process again for the next bug with every new member. If we were to do this review-revision process on a mailing list filled with Ubuntu reviewers and members interested in fixing bugs in the package, others will also get familiar, step-up to review the patches and eventually only ready-to-be-committed patches land in upstream bug-trackers. Upstream developers are always happy to have new contributors and often looking for new contributors. Where do they find them? We eventually hope the team has a huge pool of fresh talent, ripe for the pickings.
As an Ubuntu Advocate, have you had trouble directing people interested in fixing Ubuntu bugs? We hope the team is a contact point for people interested in getting into Ubuntu development and fixing bugs.
Papercuts Ninja team is a team for everyone to be excited about!
For more information, kindly refer to the wiki.
Interested in running Ubuntu Desktop in your organisation?
Snapcraft squad Report a Snap Last year, a snap was found in the Snap Store using computing resources for bitcoin mining without user consent. This software was retired from the Store after further investigation and highlighted the need…
ACPICA is an open-source project that provides an operating system (OS)-independent reference implementation. It also contains a list of utilities such as ASL compiler (iasl), acpiexec (an AML emulator). However, AML debugging on Linux in…
Updating the design of the Ubuntu Releases website using Vanilla Framework