I am new to this group and want to make sure that I am following the conventions of the group. As such I have a few questions about the way I think things should work based on reading the information at apache.org.
This may apply more to a more mature Apache project and not to an incubator like Stonehenge but I would like to make sure that I am not doing things against the culture of the group. 1. When an issue (bug, enhancement, new feature) is discovered it is entered into the JIRA tool at http://issues.apache.org/jira/browse/STONEHENGE. The group can then vote on the issue to decide which ones should be worked on. Q1: When I enter an issue I get an e-mail but there doesn't appear to be a general announcement. Is the best practice to send an e-mail to the stonehenge-dev group or is it the responsibility of everyone on the group to check the web site or RSS feed frequently? Q2: When I look at the jira voting mechanisms there seems to be a way to vote +1 but not a -1 if you have a dissenting vote. Is the developer list the correct way to discuss the issue and eventually vote an issue up or down? Q3: Is there a generally agreed upon time that one should wait for input on issues before assuming that "silence is compliance" and begin working on the issue? 2. At some point work is begun on the issue and the status is updated to "In Progress". Work proceeds and eventually is completed. At this point if the person doing the work is a committer, they can commit the changes to the repository and an e-mail goes out to let everyone know there are updates to the tree. If the person is not a committer then I believe the process is 2.1 The person completing the work should create a patch file and attach it to the jira issue and 2.2 send an e-mail to the developer list announcing that a patch is completed. Q4: I have seen that each file needs to have a standard header to pass the RAT tool. Beyond that is there a convention for commenting code with the jira issue number or some other data (date, developer, etc.) that shows the reason for the change beyond normal documenting of code to explain what the code does? 3. A committer will look at the submitted patch and determine if it fixes the issue and should be added to the source control repository. If the patch is deemed sufficient then the contributor will also mark the jira issue as resolved. Q5: As everyone is a volunteer and busy with other things is there a generally agreed upon waiting period to wait before asking about the status of a submitted patch that hasn't been accepted or rejected? Q6: Out of curiosity and to understand the process better, do the committers vote on a patch or is the opinion of a single committer sufficient? Scott Golightly
