First, I want to digress into an explanation of the Twisted methodology,
Ultimate Quality Development System. The name sounds fancy, the methodology is straightforward. It starts with a clear ticket describing the issue and perhaps how it is going to be handled. A patch, in the form of a patch file or an SVN branch is written. It is reviewed, where it might be rejected or accepted. If it is rejected, the patch is rewritten to address the concerns, and then reviewed again. If it is accepted, it is merged into the trunk and the ticket is closed. Among the issues addressed in reviews are test coverage, documentation and coding style issues, as well as functional issues.
The UQDS is well documented on Twisted’s site. The short explanation above is by no means exhaustive, but the documentation on the Twisted wiki is. It is especially geared to new contributors wanting to help out.
Twisted has many subtle issues. However, it also has many straightforward
issues that nobody in the core development team has had the resources to address yet. We maintain a list of easy tickets through a keyword, and this list is accessible through one of the reports on the Twisted site.
However, for those not comfortable delving into the code base right in, there are also other ways to contribute. One of the bottlenecks that the project experiences is tickets which are waiting for review. While the final review can only be done by a committer, a review of pending patches is still something a newcomer can do. Those which have not gone through any review cycles are unlikely to be perfect — something was probably forgotten. Finding those issues and pointing them to the originator of the patch frees up resources from the core team, and allows them to move faster. For those cases where a patch is up to current standards, a review which does not remove the “needed review” flag but that explains what the reviewer has gone through and which checks the patch passed makes the job of the final reviewer that much easier.
There are two big advantages to help with Twisted. Twisted is a project with high visibility, so help with it is a useful merit badge. For programmers wanting to have their name visible in the Python world, this is a
straightforward path to untold fame and riches. The other advantage is that
this is a way to con the Twisted core team into free mentoring. The team
is nice and considerate, and will point out any issues that the code has, thus giving a valuable lesson in Python programming.
There is a report called “Review tickets in the order they should be reviewed”. Opening this report, and reviewing the tickets, is one of the most useful ways to help Twisted. Another way is to choose a module, look at which Python 3 compatibility warnings it gets when ran with Python 2.6 with 3 warnings turned on, and fix all of those. This is straightforward work which deals with one of the biggest Python 3 acceptance hurdles.