From 3482f1022bb61fcf2fad9f57ae32fad1883337d1 Mon Sep 17 00:00:00 2001
From: Robert Gemmell <robbie@apache.org>
Date: Mon, 5 Jul 2010 20:39:44 +0000
Subject: Transition the Gettting Involved front page and Project Etiquette
 guide to the new website model and update menu accordingly.

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@960688 13f79535-47bb-0310-9956-ffa450edef68
---
 doc/website/content/getting_involved.html          | 49 +++++++++++++
 .../content/qpid_project_etiquette_guide.html      | 84 ++++++++++++++++++++++
 doc/website/template/template.html                 |  2 +-
 3 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 doc/website/content/getting_involved.html
 create mode 100644 doc/website/content/qpid_project_etiquette_guide.html

diff --git a/doc/website/content/getting_involved.html b/doc/website/content/getting_involved.html
new file mode 100644
index 0000000000..6becee63ba
--- /dev/null
+++ b/doc/website/content/getting_involved.html
@@ -0,0 +1,49 @@
+<div class="main_text_area_body">
+
+<h1>Getting Involved</h1>
+
+<h2><a name="GettingInvolved-TherearemanywaysyoucangetinvolvedinQpid%3A"></a>Join in</h2>
+
+<ol>
+    <li>Participate on the <a href="mailing_lists.html" title="Mailing Lists">Mailing Lists</a>.</li>
+    <li>Contibute via <a href="http://issues.apache.org/jira/browse/qpid">JIRA issues</a>. Remember that all patches must be attached to a JIRA with the ASL usage granted or we can't use it!</li>
+    <li>Review the current code.</li>
+    <li>Help write user documentation.</li>
+    <li>Help write user examples.</li>
+    <li>Most definitely add more tests.</li>
+</ol>
+
+<p>Please be sure to take a look at the coding guidelines for the section of the project that you contribute to:</p>
+
+<ul>
+	<li><a href="https://cwiki.apache.org/qpid/java-coding-standards.html">Java Coding Standards</a></li>
+	<li><a href="https://cwiki.apache.org/qpid/cppstyleguide.html">C++ Coding Standards</a></li>
+
+	<li><a href="https://cwiki.apache.org/qpid/cpptips.html">C++ Tips</a></li>
+	<li><a href="https://cwiki.apache.org/qpid/osvc.html">OS version considerations</a></li>
+</ul>
+
+<h2><a name="GettingInvolved-ProjectEtiquette"></a>Project Etiquette</h2>
+
+<p>Please read and digest our <a href="qpid_project_etiquette_guide.html" title="Qpid Project Etiquette Guide">Qpid Project Etiquette Guide</a>. This is a key guide for new contributers and required reading.</p>
+
+<h2><a name="GettingInvolved-Becomingacommitter%3A"></a>Becoming a Committer</h2>
+
+<p>Qpid uses the following guidelines for voting in new committers. First off we would like new committers to have provided meaningful contribution to the project. By contributions we include development (tests, features, examples) or documentation through patches and interactions with the project through lists and JIRA. It should be noted that as we send our JIRA to the dev list, thus some people filter the JIRA's to limit traffic. It is thus good to cross post something to the dev list every now and again, if the discussion is being held primarily on JIRA.</p>
+
+<p>The key question is what does the Qpid project consider to be a meaningful contribution to be come a committer. As this bar is set for all new commiters Qpid will be conservative in general with adding new committers.</p>
+
+<p>The Qpid project will look to see if someone consistently provides quality contributions and interactions with the project over a period of several weeks. Based on that the PMC will vote the new committers onto the project. </p>
+
+<p>If you have any question please mail <a href="mailto:dev@qpid.apache.org">dev@qpid.apache.org</a> or <a href="mailto:private@qpid.apache.org">private@qpid.apache.org</a> </p>
+
+<p>Many thanks for you interest,<br />
+
+The Qpid Team.</p>
+
+<h2><a name="GettingInvolved-JoiningthePMC"></a>Joining the PMC</h2>
+
+<p>Nominations for Qpid PMC membership will be voted on by the Qpid PMC.</p>
+
+</div>
+
diff --git a/doc/website/content/qpid_project_etiquette_guide.html b/doc/website/content/qpid_project_etiquette_guide.html
new file mode 100644
index 0000000000..16b2ab91d0
--- /dev/null
+++ b/doc/website/content/qpid_project_etiquette_guide.html
@@ -0,0 +1,84 @@
+<div class="main_text_area_body">
+
+<h1>Qpid Project Etiquette Guide</h1>
+
+<h2><a name="QpidProjectEtiquetteGuide-Purpose"></a>Purpose</h2>
+
+<p>This guide, written by Rafael Schloming, gives both Qpid committers and submitters a useful introduction to project etiquette, shedding light on how we do things &amp; why. Following this etiquette makes the path to righteousness less long and winding !</p>
+
+<h2><a name="QpidProjectEtiquetteGuide-Maintainers"></a>Maintainers</h2>
+
+<p>The Qpid project consists of a number of major components spread across almost as many different languages. Thus it is rare for qpid committers to be experts in every single area of the project.</p>
+
+<p>As such it is expected that qpid committers make some effort to reach out to their teammates before directly modifying components that are outside their chosen areas. </p>
+
+<p>You should use the dev list to reach out to Qpid developers and comment on any JIRAs you're progressing.</p>
+
+<h2><a name="QpidProjectEtiquetteGuide-PatchSubmission"></a>Patch Submission</h2>
+
+<p>As a committer it can be difficult to decide whether/how to provide feedback when someone submits a patch. Often it is tempting to just fix up the patch and avoid the slower and sometimes awkward process of telling someone that they got some part of it wrong. </p>
+
+<p>However, it is necessary to ensure that those who submit patches get to learn what they need to know in order to become a valued qpid committer.</p>
+
+<p>In that spirit, here are a few guidelines for contributing patch submissions and how we handle them:</p>
+
+<ul>
+	<li>Submitters should produce the final patch(s) as applied to the tree. Producing a patch that needs little or no rework is a key skill for a qpid committer.</li>
+
+	<li>Maintainers may make requests for 'trivial' updates to the patch. Such requests are vital to ensuring that contributers	get familiar with subtle yet important aspects of the code, stylistic conventions, etc.</li>
+
+	<li>Make sure the submitter is familiar with project etiquette so they understand why we make seemingly trivial requests. We'll ask new contributers to read this etiquette info for that reason !</li>
+
+	<li>A one-time patch from someone passing through may need nothing more than a polite thank you regardless of the content. If a submitter does aim for committership, best to make it plain you're planning to stay around on the project.</li>
+
+	<li>Break up unrelated changes. It wouldn't be considered correct for a committer to glom together too many unrelated changes within a single commit, and so we won't commit this kind of patch from submitters.</li>
+
+	<li>You need a JIRA for any patch to be attached to, which should accurately describe the change.</li>
+</ul>
+
+
+<h2><a name="QpidProjectEtiquetteGuide-BigIdeas"></a>Big Ideas</h2>
+
+<p>Every so often someone has a Big Idea that they get excited about and want to go do. They generally mail the list about it to give people the opportunity to comment, and then when nobody says anything they go off and do it.</p>
+
+<p>Fast forward six months later they commit/merge/enable/publish the result of their Big Idea, and suddenly everyone understands the full implications, and not everyone is happy. </p>
+
+<h3><a name="QpidProjectEtiquetteGuide-Guidelines"></a>Guidelines</h3>
+
+<p>So, here are a few guidelines for making sure this doesn't happen, starting with how to write a good proposal for a Big Idea:</p>
+
+<ul>
+	<li>Make sure your proposal is recognizable as a proposal. An easy way to avoid ambiguity is to start a new thread for your proposal and stick &quot;proposal&quot; somewhere in the subject.</li>
+
+	<li>Understand who and what your proposal effects, and make this clear. If you think X's implementation of Y doesn't deserve to live and you're going to rewrite the whole thing from scratch then make this very clear so X can object sooner rather than later.</li>
+
+	<li>Make sure you call out loudly that you intend to kill feature A, even if you think no-one on earth should care.</li>
+
+	<li>Even if you're going to write an Atari emulator, and you're 100% sure that it won't overlap with anything in the rest of the project, make sure you understand how and why it relates to the rest of the project in general, and make that clear.</li>
+
+	<li>Be concrete. Often a proposal of the form &quot;hey, I did a little of this, here is a proof-of-concept, I'd like to do it for real now&quot; is far more effective than a proposal of the form &quot;hey, I have this vague idea about this, I'm going to vaguely suggest it would be good if someone did it&quot;.</li>
+
+	<li>Talk about the long term implications of your proposal. If it's code then someone needs to maintain it, and committers will expect this to be you. Make clear your intentions.</li>
+
+	<li>Never assume silence implies complicity, more likely it means people didn't understand the implications of your proposal, or didn't have time to figure out why they didn't like it. Ask again !</li>
+
+	<li>The bigger your idea is, the more time and effort you should spend on the proposal, and ensuring that you get positive responses and deal with the comments and feedback provided in your actual implementation.</li>
+</ul>
+
+
+<h3><a name="QpidProjectEtiquetteGuide-Talkearly%2Ctalkoften"></a>Talk early, talk often</h3>
+
+<p>No matter how incredibly excellent your proposal is, there is going to need to be some discussion before the result of your Big Idea is blessed. Here are some things you can do to help that discussion go smoothly:</p>
+
+<ul>
+	<li>Make frequent progress reports. Every hour/day/week/month you spend working without telling people what you're doing is an hour/day/week/month of your time that you risk wasting.</li>
+
+	<li>Define milestones and make them visible to the rest of the project. Just like a concrete proof-of-concept can help a proposal, it helps to give people a concrete look at what you're doing while it's in progress. This can go a long way towards avoiding surprises.</li>
+</ul>
+
+<h3><a name="QpidProjectEtiquetteGuide-Andfinally....."></a>And finally .....</h3>
+
+<p>When the time does come to commit/merge/enable/publish your Big Idea, it really shouldn't be a surprise to anyone if you've followed the steps up until now, but make sure you let people know in advance by making note in your final few progress reports of when you expect to be finished, and sending a note to the dev list a day or so before you flip the big switch.</p>
+
+</div>
+
diff --git a/doc/website/template/template.html b/doc/website/template/template.html
index 5e4b2e1eab..3ae98bcd7a 100644
--- a/doc/website/template/template.html
+++ b/doc/website/template/template.html
@@ -66,7 +66,7 @@
 	<div class="menu_box_body">
 	  <h3>Community</h3>
 	  <ul>
-	    <li><a href="https://cwiki.apache.org/qpid/getting-involved.html">Getting Involved</a></li>
+	    <li><a href="getting_involved.html">Getting Involved</a></li>
 	    <li><a href="source_repository.html">Source Repository</a></li>
 	    <li><a href="mailing_lists.html">Mailing Lists</a></li>
 	    <li><a href="https://cwiki.apache.org/qpid/">Wiki</a></li>
-- 
cgit v1.2.1