Every volunteer project obtains its strength from the people involved in it. We invite you to participate as much or as little as you choose. The roles and responsibilities that people can assume in the project are based on merit. Everybody's input matters!
Here is one developer's advice how to get involved. It specifically talks about Tomcat, but the general idea can applied to any of the Apache Projects.
Here is another comment that was sent to the Jakarta Turbine Mailing List about the open source process and the contrast between how an open source product and a proprietary product improve through the user community.
While written for ASF developers, the Rules for Revolutionaries provides insight into how the collaborative process works, and how our process differs from working on a hierarchical team.
Just using the products is a very important role. We need people who will report issues, contribute patches, suggest features, and so forth. Your feedback helps the technology to evolve.
| [top] |
There are a variety of ways to participate. Regardless of how you choose to participate, we suggest you join our mailing lists.
Please do be sure to turn off HTML in your email client before posting.
| [top] |
A patch is a machine-readable script that can automatically recreate a change to a text file, including source code and documentation. The patch format is also human-readable. Developers often pass patches around to discuss a change before applying it to the main repository.
The best way to affect a change to the source code or documentation is to provide a patch. Pluto committers can then review your patch and decide whether to apply it to the main repository.
To create a patch, you first have to checkout a copy of the source code or documentation from the main repository. You can then change your copy, and create the patch using a simple Subversion command, like this:
svn diff Main.java patchfile.txt
Then, create a JIRA issue about the change, and attach the patch file.
Some Apache projects ask that you to submit your patch to the mailing list. We would prefer that you create a JIRA issue and then attach the patch to the issue. To do this, you must first create the issue, and then modify the report to add your patch. We realize this is a bit clumsy, but it keeps us from losing things, and helps to ensure that your patch will be attended.
The NetBeans community also has a helpful section on the subject of creating patches.
| [top] |
Tracking of defect reports and enhancement suggestions for Apache Pluto products is handled through the Apache Pluto JIRA instance. Please select the appropriate Pluto product from the list, and then select the component to which you feel this report relates. You will automatically be notified by email as the status of your defect or enhancement report changes. Please be sure to read How to Report Bugs Effectively before posting a report.
If you can't write a patch to address your issue, a unit test that demonstrates the problem is also welcome. (And, of course, unit tests that prove your patch works are equally welcome.)
If the defect or feature is already being tracked, you can vote for the issue and call more attention to it. Each user can cast up to six votes at a time.
If there is a patch attached to the issue, you can also try applying to your local copy of Pluto, and report whether it worked for you. Feedback from developers regarding a proposed patch is really quite helpful. Don't hesitate to add a "works for me" note to a ticket if you've tried the patch yourself and found it useful.
Feature suggestions are also maintained in the JIRA issue tracker.
| [top] |
A very good place to start is by reviewing the list of open issues and pending feature suggestions in the issue tracker. If you see an issue that needs a patch you can write, feel free to annex your patch. If you seen an issue that needs a unit test to prove its fixed, feel free to annex your test case. If someone has posted a patch to an issue you'd like to see resolved, apply the patch to your local development copy of Pluto. Then let us know if it works for you, and if it does, cast your vote for the issue and its patch.
If none of the pending issues scratch your itch, another good place to start is by contributing unit tests for existing features (even those that still work).
You can upload a proposed patch to either the code or documentation by creating a feature suggestion in the issue tracker. After creating the ticket. you can go back and upload a file containing your patch.
| [top] |
The same way you contribute to the source code. All documentation is generated using maven.
| [top] |
Here is the truth regarding releases:
Apache products are released on the basis of merit, and ~not~ according to a strict timetable. The volunteers devote whatever time they can to work on the product. But all volunteers have real jobs and real lives, that do take precedence. Since Pluto does not have paid personnel working on the project, we simply cannot make date-oriented commitments.
The bottom line is that Apache takes releases very seriously. We do not compromise the quality of our software by watching the calendar (and then ship something ready or not). A release is ready when it is ready.
That may sound flip, but it ~is~ the truth. The delivery of production-quality, leading-edge software is not something anyone can prognosticate. If anyone tries, they are lying to you. That, we won't do ;-)
What we ~will~ do is release all of our development software as soon as it is developed. This way you can judge for yourself how quickly the development is proceeding, and whether what is being developed will meet your needs. If you need a feature right now, you can use the nightly build, or roll your own patch. There are no internal code repositories, private development lists, secret chat rooms, or conference calls. What you see is what we got. If you are following the DEV list, then you know everything the developers know. Really, you do.
So, what do you tell your team? If you can ship your application based on the nightly build of your choice, then consider that an option. You can still ship yours, even if we don't ship ours, and you will have access to all the latest patches or enhancements. (Just like we were working down the hall.) If you can only ship your application based on a release build of Pluto, then you should base your development on the release build of Pluto, and keep an eye on what is coming down the pipeline. This way you are at least forewarned and forearmed.
| [top] |
A guiding principle of the Apache Software Foundation is "them that do the work, make the decisions". This phrase is actually a double-entendre. A project will make some decisions by voting (very few), but the real decisions are made when a volunteer actually does the work. Unless someone volunteers to do the work, other decisions are meaningless.
In an ASF project, like Pluto, volunteers who make sustained contributions to the project are invited to become "Committers". In due course, Committers are invited to join the Project Management Committee (PMC). A goal of the ASF is for all Committers to be on the PMC.
By "sustained", we mean that an individual has been active in the project for at least six months. The contributions should come in the form of both patches (to code or documentation), and posts to the mailing lists. Patches must be competent and accepted into the repository. Posts must be consistently helpful, friendly, and collaborative. The most important characteristic in a prospective Committer is an amicable demeanor that fosters goodwill.
As PMC members take note of Portals developers who meet our qualifications, one of us will call for a vote on the internal PMC mailing list. (This usually happens when someone gets tired of applying the volunteer's patches!) The internal list is rarely used, and it is never used for development discussions. If the PMC vote passes, we will send the developer a invitation privately, to give the individual a chance to accept or discretely decline. If the candidate is able to accept, the PMC will announce the new member on the dev list.
For more about decision-making, see "How the ASF Works" and the
| [top] |