Contributing to ]project-open[
Where should I start to add new code?
Here are some suggestions if you want to start coding for an Open Source project such as ]project-open[:
- Read a lot of code, and learn from that (I've never seen a book that stressed this enough, but it is critical, and you'll read much more than you write, especially with Open Source)
- When reading code, consult include files for info on library functions (Learn how to grep for the function or structure you are looking for)
- Start small, with one-line changes to existing programs (You don't have to understand too much to do this in many cases)
- Write your own small programs just to learn the language and libraries
- Start off commenting existing code where it needs it
- Write some documentation on the architecture of the program
- Learn how to use all the tools (CVS, diff, etc.)
- Experiment by making changes to your local copy of the code
- Test your code thoroughly before you submit it
- Adhere to the maintainer's coding and formatting standards
- and last but not least: Don't get discouraged when your patches are rejected (they will be!)
How to transmit patches?
1. Email subject format
In case you transmit the patch by email, please use the following format for the subject:
PATCH [VERSION] [PACKAGE-KEY][FILE NAME]: [SUMMARY]
- For [Version] please look up the package version in /acs-admin/apm/
- [PACKAGE-KEY] can be also found at /acs-admin/apm/
- Please keep your overall subject line under 65 characters if possible
Example:
PATCH 3.4.0.2.0 intranet-core /www/projects/index.tcl : Set focus on search field
2. Email body contents: description
Include the output of
cvs diff <filename>
in the body of the email.
3. One patch per email
Even when you are resending a change for the 5th time, resist the urge to attach 20 patches to a single email. If you do send multiple emails, make sure the second and subsequent emails are sent as replies to the first, to keep them all together in a thread.
5. Sign your work
The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch. The rules are pretty simple: if you can certify the below:
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
then you just add a line at the end of your patch description, saying
Signed-off-by: Random J Developer <random@developer.org>
How to Contribute to Open Source Without Coding
The following is based on what was contributed by Craig Buchek to the St. Louis Unix Users Group listserv on 6 February 2002.
Actually, there are plenty of ways to contribute to ]po[ without coding:
- Submit bug reports
- Suggest new features and options
- Make other comments on how to improve the the quality of the program
- Help write good documentation
- Translate the documentation (and program text) into another language
- Read existing documentation, follow the examples, and make corrections
- Correct spelling and grammar mistakes in documentation
- Develop spelling and grammar style conventions for documentors
- Build a glossary of technical terms
- Convert documentation into more useful formats (i.e. XOWIKI)
- Create screencasts, diagrams, screen-shots, and graphics for documentation
- Submit graphics (icons, backgrounds) to use in the program
- Help other people learn how to use the program (answer questions on the forum)
- Write an email expressing your appreciation for the programs you use
- Write a book
- Help write articles
- Design a better user interface
- Run usability studies
- Create validation or regression test cases
- See how a program handles streams of random data
- Package the application for a particular Linux distro
- Get the program to compile on a new platform
- Provide training
- Read relevant standards and make sure the program follows them
- Convince people to chose Open Source products when possible
- Write up case studies of successful Open Source implementations
How can you tell us about bugs you found?
- For rather minor bugs please use our bug tracker at sourceforge. For more complex topics please send us an email.
- 3 things are most important when informing us know about bugs: Screenshots, Screenshots and guess what? yes: Screenshots
- Make sure that the URL of the page the error occurred on is visible on the screenshots or mention it in the the email/forum
- Describe the problem as detailed as possible
- Tell us which version of ]po[ you are using
RSS feed
