1. When will our bugs be fixed? When will our new features be added? When will the next release come out? Is my server up-to-date? Users Committers Program Management Committee Release Manager Report Bugs Request New Features Submit Bug Fixes & Minor Features Contribute code for new Release Review patches Documentation Testing Review and Vote on Patches Commit Patches to CVS Promote Developers Mentor Developers Determine the Project Roadmap Oversight the Project Interact with the ASF Responsible for final build Where can I get help?Where can I get help? How can Will my Code be Accepted?How can Will my Code be Accepted? I become a Committer? Should I veto this? Bugzilla Mailing Lists CVS Apache Website Is this ready to release? What if the release is bad? When should we announce this? What new features are essential? What does the community want? What is best for long term dev? What are other projects doing? Developers

2. User Concerns Users can keep up to date by subscribing to the mailing list which will announce new releases and new patches Developers will correspond with users via email when they are working on a bug they submitted or a new feature they requested

3. Report Bugs and Request New Features Users report bugs and request new features through the Apache Bug database (Bugzilla). Users should first install the most recent version of the HTTPD server and update all patches to ensure the bug has not already been fixed Next they should search Bugzilla to see if it has already been reported or currently is being worked on Finally, if it has not been fixed or reported they add their bug report or new feature report to Bugzilla

4. Developer Concerns Developers can get help from Committers who serve as mentors Mailing list Guidelines on the project website Developers are dependent on Committers to accept or reject their patch and then release it

5. Submission of Work Code and Documentation is submitted and voted upon for release For patches, committers follow a commit-then- review policy (commit and revoke if anyone objects to it later) For new features as well as planned release’s feature, committers follow a review-then-commit policy (must be unanimously approved by everyone before being committed)

6. Review Patches Developers can review patches and vote on them However only committers votes count (i.e. the binding votes) A developer’s vote is also considered as binding if and only if he or she is the patch owner Otherwise, the vote is just a standing opinion

7. Documentation Documentation is treated just like source code Submitted into the CVS only by committers Developer contributes new content as patches Documentation patches are then voted on by committers

8. Testing Developers mainly participate in Alpha and Beta Testing Testing version of software is distributed in a different branch of the source code repository then the released version of the code Only developers or high ‘level’ can access this Final Testing (i.e. advance to G.A.) is performed on the Apache Software Foundation web server, hosting the website for at least 3 days before public announcement is issued

9. Committers Concerns How to determine the quality of the patches? –Commit-then-review? –Review-then-commit? –Vetoes?

10. Patches Currently, patches are treated with the commit- then-review policy Hence, it is only governed by the lacy consensus

11. Promote and Mentor Developers Ongoing advising and monitoring the quality of code contribution by developers Acknowledge developer’s consistent high-quality contribution by recommending promotion of status –Must be unanimously agreed among all committers

12. PMC Concerns What are the interests of the general community (i.e. users)? –Interact with other project communities (e.g. Mozilla, Jarkata, NetBeans, etc.) What is are the interests of the project community (i.e. developers, committers, etc)? –Extract information from discussion in conference (e.g. Apachecon) and mailing list (e.g. developers) Where to gather milestones for the next release –From Bugzilla, find PRs with a “enhancement” severity

13. Project Goals and Community Oversight Make sure the project’s progress is align with the ‘STATUS’ file Keep the interaction among committers on-going Resolve any conflicts within the community Ensure community standard is maintained and in active

14. Interaction with ASF Discussion the project direction with –the Board of Directors – Foundation Members of ASF Align the project direction with the business goals Bring up any possible issues encountered (e.g. licensing issues?)

15. Release Manager Concerns Which release ‘style’ should I employ? –“quick-and-efficient”: building the source and tagging it as distribution, before a thorough testing –“slow-but-reliable”: building the source without tagging as distribution, and wait for a thorough testing What is the appropriate time to release? –Follow the guideline from the ‘STATUS’ file –Interaction with PMC

16. Releasing the Final Build Responsible for all 3 stages –Alpha ? –Beta After vigorous testing from Alpha Will be run on web server hosting the http://www.apache.org/ for at least 3 days, before advancing to GA stage http://www.apache.org/ –General Availability (GA) Announcement is sent to mailing list In each stage, do the build-tag-tarball-announce