|Version 4 (modified by rwall, 2 years ago) (diff)|
Contributing To Twisted (DRAFT)
This is a one page summary of the ways that you or your organization can contribute to Twisted.
This is a draft document which is intended to eventually replace wiki:ContributingToTwistedLabs.
There are many ways individuals and organizations can make contributions to Twisted.
Many open source projects are perpetually crunched for volunteer labor. Twisted is no different in this respect — we could always use more help from the community. However, we are lucky to have something that most projects don't; the ability to convert dollars directly into maintenance that benefits the project.
When you contribute money to the Twisted project, you are directly contributing to get bugs fixed, features implemented, and tickets reviewed. Donations are tax-deductible and can be made via Google Checkout or Paypal or directly to the Twisted Software Foundation.
Report Bugs / Suggest Enhancements
- Search for an existing ticket: Search the bugtracker for any existing tickets that are similar to the ones you are planning to file.
- Introduce yourself: If you didn't find an existing ticket, introduce yourself on the mailing list or in IRC and discuss your proposed bug or enhancement with the Twisted Developers. They may be able to point you to an existing related ticket or help you structure your proposed enhancement so that it can be quickly and efficiently integrated into Twisted.
See the Twisted Community page for the various ways to contact Twisted Developers.
- Register: Before you can create a new ticket you will have to create an account in the Twisted Trac system. Visit the registration page and choose a username and password.
Choose a unique password. Do not use the same password that you use for accessing other websites.
- Create a ticket: There are three types of ticket described in the FilingTickets section of the TwistedDevelopment guide.
They are duplicated here for convenience:
- are used for feature additions. These typically take the form of a new API or an expansion of an existing API. Enhancement tickets should clearly describe the desired feature. The more well specified a feature is, the more likely it is to be implemented (and importantly, the more likely it is that what is implemented will actually be what the reporter wanted!) and the easier it is to implement. Remember that the ticket is possibly the only persistent record of the feature request. If it is not self-contained and sufficiently detailed, then it will likely fail to communicate the reporter's idea, diminishing its value (possibly all the way down to zero).
- are used to track bugs in existing APIs. Defect tickets are easier to specify than enhancements. A defect should briefly describe the problem, but the bulk of the ticket should be a runnable program (ideally in the form of a unit test) which demonstrates the bug.
- are similar to defects, but are for bugs which are introduced into APIs in newer releases of Twisted. Like defect tickets, regression tickets should have a runnable program attached to demonstrate the problem.
- Basic instructions before you start.
- Prepare. (Links to other development process related documentation - redundancy)
- Understand the development process. (Links to UQDS and Review Process)
- Also, possibly tl;dr review process
- News files! (already linked from the links above - repeating for emphasis0
- Submit for review (May contain redundant steps)
If you have commit access:
- Read CommitterChecklist.
- Twisted and SVN (howto).
Review a Ticket
- Code Review (i.e. Divmod's description of what a code review is).
- Review Process explained in detail.
Other ways to contribute
Text from OtherWaystoContribute