Author: lukaszlenart
Date: Sun Feb 9 09:43:03 2014
New Revision: 1566258
URL: http://svn.apache.org/r1566258
Log:
Converts helping to Markdown and Jekyll
Added:
struts/site/branches/jekyll-powered/content/helping.html
struts/site/branches/jekyll-powered/source/helping.md
Removed:
struts/site/branches/jekyll-powered/old-content/fml/helping.fml
Added: struts/site/branches/jekyll-powered/content/helping.html
URL:
http://svn.apache.org/viewvc/struts/site/branches/jekyll-powered/content/helping.html?rev=1566258&view=auto
==============================================================================
--- struts/site/branches/jekyll-powered/content/helping.html (added)
+++ struts/site/branches/jekyll-powered/content/helping.html Sun Feb 9
09:43:03 2014
@@ -0,0 +1,329 @@
+<!DOCTYPE html>
+<html>
+<head>
+ <meta charset="UTF-8"/>
+ <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
+ <meta name="Date-Revision-yyyymmdd" content="20140206"/>
+ <meta http-equiv="Content-Language" content="en"/>
+ <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
+
+ <title>Helping</title>
+
+ <link rel="stylesheet" href="/bootstrap/css/bootstrap.css">
+ <link rel="stylesheet" href="/css/main.css">
+
+ <script type="text/javascript" src="/js/jquery-1.11.0.min.js"></script>
+ <script type="text/javascript" src="/bootstrap/js/bootstrap.js"></script>
+ <script type="text/javascript" src="/js/community.js"></script>
+</head>
+<body>
+
+<a href="http://github.com/apache/struts";>
+ <img style="position: absolute; top: 0; right: 0; border: 0; z-index:
10000;"
src="https://s3.amazonaws.com/github/ribbons/forkme_right_red_aa0000.png";
alt="Fork me on GitHub">
+</a>
+
+<header>
+ <!-- Fixed navbar -->
+<nav>
+ <div class="navbar navbar-default navbar-fixed-top" role="navigation">
+ <div class="container">
+ <div class="navbar-collapse collapse">
+ <ul class="nav navbar-nav">
+
+ <li class="dropdown">
+ <a class="dropdown-toggle" data-toggle="dropdown" href="#">Apache
Struts <b class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li><a href="index.html">Welcome</a></li>
+ <li><a href="downloads.html">Downloads</a></li>
+ <li><a href="announce.html">Announcements</a></li>
+ <li><a href="http://www.apache.org/licenses/";>License</a></li>
+ <li><a
href="http://apache.org/foundation/thanks.html";>Thanks!</a></li>
+ <li><a
href="http://apache.org/foundation/sponsorship.html";>Sponsorship</a></li>
+ </ul>
+ </li>
+
+ <li class="dropdown">
+ <a class="dropdown-toggle" data-toggle="dropdown" href="#">Support
<b class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li><a href="mail.html">User Mailing List</a></li>
+ <li><a href="https://issues.apache.org/jira/browse/WW";>Issue
Tracker</a></li>
+ <li><a href="security.html">Reporting Security Issues</a></li>
+ </ul>
+ </li>
+
+ <li class="dropdown">
+ <a class="dropdown-toggle" data-toggle="dropdown"
href="#">Documentation <b class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li><a href="birdseye.html">Birds Eye</a></li>
+ <li><a href="primer.html">Key Technologies</a></li>
+ <li><a href="kickstart.html">Kickstart FAQ</a></li>
+ <li><a
href="https://cwiki.apache.org/confluence/display/WW/Home";>Wiki</a></li>
+ <li><a
href="http://struts.apache.org/release/2.3.x/index.html";>Struts 2</a></li>
+ <li><a
href="http://struts.apache.org/release/1.3.x/index.html";>Struts 1</a></li>
+ </ul>
+ </li>
+
+ <li class="dropdown">
+ <a class="dropdown-toggle" data-toggle="dropdown"
href="#">Contributing <b class="caret"></b></a>
+ <ul class="dropdown-menu">
+ <li><a href="youatstruts.html">You at Struts</a></li>
+ <li><a href="helping.html">How to Help FAQ</a></li>
+ <li><a href="dev-mail.html">Development Lists</a></li>
+ <li class="divider"></li>
+ <li><a href="git-for-struts.html">Git for Struts</a></li>
+ <li><a href="builds.html">Source Code</a></li>
+ <li><a href="coding-standards.html">Coding standards</a></li>
+ <li class="divider"></li>
+ <li><a href="releases.html">Release Guidelines</a></li>
+ <li><a href="bylaws.html">PMC Charter</a></li>
+ <li><a href="volunteers.html">Volunteers</a></li>
+ <li><a
href="https://git-wip-us.apache.org/repos/asf?p=struts.git";>Source
Repository</a></li>
+ </ul>
+ </li>
+
+ </ul>
+ </div>
+ <!--/.nav-collapse -->
+ </div>
+ </div>
+</nav>
+
+ <div class="container">
+ <div class="row">
+ <div class="pull-left">
+ <a href="/" id="bannerLeft">
+ <img src="/img/struts.gif" alt="Apache Struts"/>
+ </a>
+ </div>
+ <div class="pull-right"><a href="http://www.apache.org"; id="bannerRight">
+ <img src="/img/asf-logo.gif" alt="Apache Software Foundation"/>
+ </a>
+ </div>
+ </div>
+ </div>
+</header>
+
+
+<article class="container">
+ <section class="col-md-12">
+ <h1>How to Help FAQ</h1>
+
+<ul>
+<li><h3>What can my company do to help support Apache Struts?</h3>
+
+<p>Apache Struts is an all volunteer product. Our customers are the volunteers
who donate their time and
+energy to supporting the product. If you want to support Apache Struts, and
become one of our
+customers, then you need to get involved and become a volunteer.</p>
+
+<p>Our challenge to any team using an Apache Struts product is to donate the
time of one team member
+one afternoon a week (or more if you can spare the resources).
+Have your team member browse <a href="#issues">JIRA</a> for any issues without
a <a href="#patches">patch</a> or unit test,
+and <a href="#contribute">add the patch or test</a>. (Please note that we do
not use @author tags in our
+JavaDocs an documentation.)
+If your patch includes an @author tag, we would have to ask that it be
removed.</p>
+
+<p>If an Apache Struts product doesn't do what <em>you</em> want, it's
up to <strong>you</strong> to step up and propose the patch.
+If an Apache Struts product doesn't ship as often as you would like,
it's up to you to step up with
+the tests and fixes that get a release out the door.
+<a href="http://jakarta.apache.org/site/contributing.html";>(Like Craig
McClanahan did for Tomcat)</a>.</p>
+
+<p>If Struts does do what you want, help others become involved by turning
your war stories into FAQs
+and how-tos that we can make part of the <a
href="#documentation">documentation</a>.
+The mailing list is very active and trundling through the archives is no
picnic. We can always use
+volunteers who can reduce the best threads to coherent articles we can share
with others.</p>
+
+<p>We don't sell Struts for money, but anyone who wants to be our customer
can pay us back by donating
+the time and energy that money represents.</p></li>
+<li><h3><a name="patches"></a>How do I create a patch?</h3>
+
+<p>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.</p>
+
+<p>The best way to affect a change to the source code or documentation is to
provide a patch.
+Apache Struts committers can then review your patch and decide whether to
apply it to the main repository.</p>
+
+<p>Please be aware that the Struts project follows general coding conventions.
In short, these are
+the official Java coding conventions plus the rule to favor spaces over tabs
for indenting. See more
+details at <a
href="https://cwiki.apache.org/confluence/display/S2WIKI/Struts+2+Coding+Conventions";>Struts
2 Coding Conventions (Wiki)</a></p>
+
+<p>To create a patch, you first have to <a
href="git-for-struts.html">checkout</a> 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
+<a href="http://git-scm.com/";>Git</a> command, like this:</p>
+<div class="highlight"><pre><code class="text language-text"
data-lang="text">git diff Main.java >> patchfile.txt
+</code></pre></div>
+<p>Then, create a <a href="#issues">JIRA issue</a>about the change, and attach
the patch file.</p>
+
+<p>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.</p>
+
+<p>The <a
href="http://www.netbeans.org/community/contribute/patches.html";>NetBeans
community</a> also has a helpful section on the
+subject of creating patches.</p></li>
+<li><h3><a name="issues"></a>How can I report defects or suggest features?</h3>
+
+<p>Tracking of defect reports and enhancement suggestions for Apache Struts
products is handled through the
+<a href="https://issues.apache.org/jira/browse/WW";>Apache Struts JIRA
instance</a>.
+Please select the appropriate Apache Struts 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
+<a href="http://www.chiark.greenend.org.uk/%7Esgtatham/bugs.html";>How to
Report Bugs Effectively</a>
+before posting a report.</p>
+
+<p>If you can't write a <a href="#patches">patch</a> 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.)</p>
+
+<p>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.</p>
+
+<p>If there is a patch attached to the issue, you can also try applying to
your local copy of Struts,
+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.</p>
+
+<p>Feature suggestions are also maintained in the <a
href="https://issues.apache.org/jira/browse/WW";>JIRA issue tracker</a>.</p></li>
+<li><h3><a name="contribute"></a>How can I contribute to the Struts source
code?</h3>
+
+<p>A very good place to start is by <strong>reviewing the list of open
issues</strong> and pending feature suggestions in the
+<a href="#issues">issue tracker</a>.
+If you see an issue that needs a patch you can write, feel free to annex your
patch. If you see an issue
+that needs a unit test to prove it's 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 Struts.
+Then let us know if it works for you, and if it does, cast your vote for the
issue and its patch.</p>
+
+<p>If none of the pending issues scratch your itch, another good place to
start is by <strong>contributing unit tests</strong>
+for existing features (even those that still work).</p>
+
+<p>You can upload a proposed <a href="#patches">patch</a> to either the code
or documentation by creating a feature
+suggestion in the <a href="#issues">issue tracker</a>.
+<strong>After creating the ticket</strong> you can go back and upload a file
containing your patch.</p>
+
+<p>Our current approach to <a href="kickstart.html#tests">unit testing</a>
works fairly well for exercising most method-level
+stuff, but does not really address situations of dynamic behavior -- most
particularly the execution of custom tags
+for Struts.
+You can try to fake what a JSP container does, but a much more reliable
testing regime would actually execute
+the tag in a real container.</p></li>
+<li><h3><a name="documentation"></a>How can I contribute to the
documentation?</h3>
+
+<p>The Struts 2 documentation is maintained using the Atlassian Confluence
wiki software and automatically
+exported to HTML for viewing on the website. To help with the Struts 2
documentation, you must create
+an account at <a
href="http://cwiki.apache.org/confluence";>cwki.apache.org/confluence</a>, AND
you must file a
+<a href="http://apache.org/licenses/icla.txt";>Contributor License
Agreement</a> with the ASF.</p>
+
+<p>Other ways to help out with the documentation is to just leave a comment on
a page that needs fixing.
+If you have a cwiki Confluence account, you can also create pages on the
+<a href="http://cwiki.apache.org/S2WIKI/home.html";>Struts 2 Wiki</a> without
filing a CLA.</p>
+
+<p>If you are submitting new material, it is important to decide exactly where
you would put this
+in relation to the rest of the documentation.
+Again, someone has to figure that out before it can be added, and that someone
might as well be you.</p></li>
+<li><h3><a name="release"></a>So when is the next release coming out?</h3>
+
+<p>Here is the truth regarding releases:</p>
+
+<p>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 Struts does not have paid
personnel working on the project,
+we simply cannot make date-oriented commitments.</p>
+
+<p>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.</p>
+
+<p>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 ;-)</p>
+
+<p>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.</p>
+
+<p><em>So, what do you tell your team</em>?
+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 Struts, then you should base your development on the release build of
Struts,
+and keep an eye on what is coming down the pipeline.
+This way you are at least forewarned and forearmed.</p></li>
+<li><h3><a name="release_help"></a>What can I do to help the next release
along?</h3>
+
+<ul>
+<li>Most importantly, download the latest <a
href="builds.html#NightlyBuilds">nightly build</a> or development release
+and test it against your own applications. Report any and all issues or
suspected issues to
+<a href="#issues">the issue tracker</a>.
+The sooner we resolve any problems, the fewer betas or release candidates we
will have to distribute before we are done.
+(How do we know when we're done? -- When we run out of issues =:o) The
sooner we find them, the sooner we are done.)</li>
+<li><strong>Contribute <a href="kickstart.html#tests">unit tests</a></strong>.
The closer we get to a release, the more we worry
+about breaking something. The more tests we have, the more confident we can be
when applying patches.
+Tests that prove that a pending issue is actually a defect are the most
welcome ones.
+But we are eager for any and all tests for any and all features, even those
that still work =:0).</li>
+<li><strong>Review the list of issues</strong> at <a href="#issues">the issue
tracker</a>. If there are any to which you can respond, please
+do. If there any patches posted, feel free to test them your system, report
the results, and cast your vote
+if they work.</li>
+<li><em>Confirm an issue's category and status</em>. Newbies often post
feature suggestions or help-desk
+questions as "bugs". This bloats the list of fixes we (apparently)
need to apply before the next
+beta, making it hard to see the forest for the trees.
+If an issue doesn't seem to be categorized correctly, exercise your best
judgment and change it.
+If one ticket seems like a duplicate of another, go ahead and enter the change.
+Every modification to the ticket is echoed to the DEV list and automatically
subjected to peer review.
+Err on the side of doing.</li>
+<li>Use the issue tracker to <strong>vote for issues</strong> you feel should
be handled first. If an issue on your
+ballot doesn't include a patch, feel free to try coding one yourself. (In
a meritocracy, patches are
+the only votes that matter.)
+Dozens of developers have contributed code or documentation to Struts. You can
too =:0)</li>
+<li><strong>Answer questions on the user list</strong>. The Committers only
have a limited amount of time to volunteer.
+If Developers are supporting each other on the lists, the Committers have more
time to spend on the next
+release.</li>
+</ul></li>
+<li><h3><a name="decides_help"></a>How can I help make the decisions?</h3>
+
+<p>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.</p>
+
+<p>In an ASF project, like Apache Struts, 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.</p>
+
+<p>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.</p>
+
+<p>As PMC members take note of Struts 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.</p>
+
+<p>For more about decision-making, see <a
href="http://apache.org/foundation/how-it-works.html";>How the ASF Works</a>
+and the <a href="bylaws.html">Apache Struts Charter</a>. For more about
project infrastructure,
+see "Project Maintenance and Resources" in the <a
href="http://wiki.apache.org/struts/";>Struts 1 wiki</a>.</p></li>
+</ul>
+
+ </section>
+</article>
+
+ <hr/>
+<footer class="container">
+ <div class="row col-md-12 text-center">
+ Copyright © 2000-2014 <a href="http://www.apache.org/";>The Apache
Software Foundation</a>. All Rights Reserved.
+ </div>
+ <div class="row col-md-12 text-center">
+ Apache Struts, Struts, Apache, the Apache feather logo, and the Apache
Struts
+ project logos are trademarks of The Apache Software Foundation.
+ </div>
+</footer>
+
+
+</body>
+</html>
Added: struts/site/branches/jekyll-powered/source/helping.md
URL:
http://svn.apache.org/viewvc/struts/site/branches/jekyll-powered/source/helping.md?rev=1566258&view=auto
==============================================================================
--- struts/site/branches/jekyll-powered/source/helping.md (added)
+++ struts/site/branches/jekyll-powered/source/helping.md Sun Feb 9 09:43:03
2014
@@ -0,0 +1,218 @@
+---
+layout: default
+title: Helping
+---
+
+# How to Help FAQ
+
+ - ### What can my company do to help support Apache Struts?
+
+ Apache Struts is an all volunteer product. Our customers are the volunteers
who donate their time and
+ energy to supporting the product. If you want to support Apache Struts, and
become one of our
+ customers, then you need to get involved and become a volunteer.
+
+ Our challenge to any team using an Apache Struts product is to donate the
time of one team member
+ one afternoon a week (or more if you can spare the resources).
+ Have your team member browse [JIRA](#issues) for any issues without a
[patch](#patches) or unit test,
+ and [add the patch or test](#contribute). (Please note that we do not use
@author tags in our
+ JavaDocs an documentation.)
+ If your patch includes an @author tag, we would have to ask that it be
removed.
+
+ If an Apache Struts product doesn't do what *you* want, it's up to **you**
to step up and propose the patch.
+ If an Apache Struts product doesn't ship as often as you would like, it's up
to you to step up with
+ the tests and fixes that get a release out the door.
+ [(Like Craig McClanahan did for
Tomcat)](http://jakarta.apache.org/site/contributing.html).
+
+ If Struts does do what you want, help others become involved by turning your
war stories into FAQs
+ and how-tos that we can make part of the [documentation](#documentation).
+ The mailing list is very active and trundling through the archives is no
picnic. We can always use
+ volunteers who can reduce the best threads to coherent articles we can share
with others.
+
+ We don't sell Struts for money, but anyone who wants to be our customer can
pay us back by donating
+ the time and energy that money represents.
+
+ - ### <a name="patches"></a>How do I create a patch?
+
+ 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.
+ Apache Struts committers can then review your patch and decide whether to
apply it to the main repository.
+
+ Please be aware that the Struts project follows general coding conventions.
In short, these are
+ the official Java coding conventions plus the rule to favor spaces over tabs
for indenting. See more
+ details at [Struts 2 Coding Conventions
(Wiki)](https://cwiki.apache.org/confluence/display/S2WIKI/Struts+2+Coding+Conventions)
+
+ To create a patch, you first have to [checkout](git-for-struts.html) 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
+ [Git](http://git-scm.com/) command, like this:
+
+ git diff Main.java >> patchfile.txt
+
+ Then, create a [JIRA issue](#issues)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](http://www.netbeans.org/community/contribute/patches.html) also has
a helpful section on the
+ subject of creating patches.
+
+ - ### <a name="issues"></a>How can I report defects or suggest features?
+
+ Tracking of defect reports and enhancement suggestions for Apache Struts
products is handled through the
+ [Apache Struts JIRA instance](https://issues.apache.org/jira/browse/WW).
+ Please select the appropriate Apache Struts 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](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html)
+ before posting a report.
+
+ If you can't write a [patch](#patches) 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 Struts,
+ 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](https://issues.apache.org/jira/browse/WW).
+
+ - ### <a name="contribute"></a>How can I contribute to the Struts source
code?
+
+ A very good place to start is by **reviewing the list of open issues** and
pending feature suggestions in the
+ [issue tracker](#issues).
+ If you see an issue that needs a patch you can write, feel free to annex
your patch. If you see an issue
+ that needs a unit test to prove it's 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 Struts.
+ 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](#patches) to either the code or
documentation by creating a feature
+ suggestion in the [issue tracker](#issues).
+ **After creating the ticket** you can go back and upload a file containing
your patch.
+
+ Our current approach to [unit testing](kickstart.html#tests) works fairly
well for exercising most method-level
+ stuff, but does not really address situations of dynamic behavior -- most
particularly the execution of custom tags
+ for Struts.
+ You can try to fake what a JSP container does, but a much more reliable
testing regime would actually execute
+ the tag in a real container.
+
+ - ### <a name="documentation"></a>How can I contribute to the documentation?
+
+ The Struts 2 documentation is maintained using the Atlassian Confluence wiki
software and automatically
+ exported to HTML for viewing on the website. To help with the Struts 2
documentation, you must create
+ an account at
[cwki.apache.org/confluence](http://cwiki.apache.org/confluence), AND you must
file a
+ [Contributor License Agreement](http://apache.org/licenses/icla.txt) with
the ASF.
+
+ Other ways to help out with the documentation is to just leave a comment on
a page that needs fixing.
+ If you have a cwiki Confluence account, you can also create pages on the
+ [Struts 2 Wiki](http://cwiki.apache.org/S2WIKI/home.html) without filing a
CLA.
+
+ If you are submitting new material, it is important to decide exactly where
you would put this
+ in relation to the rest of the documentation.
+ Again, someone has to figure that out before it can be added, and that
someone might as well be you.
+
+ - ### <a name="release"></a>So when is the next release coming out?
+
+ 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 Struts 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 Struts, then you should base your development on the release build
of Struts,
+ and keep an eye on what is coming down the pipeline.
+ This way you are at least forewarned and forearmed.
+
+ - ### <a name="release_help"></a>What can I do to help the next release
along?
+
+ - Most importantly, download the latest [nightly
build](builds.html#NightlyBuilds) or development release
+ and test it against your own applications. Report any and all issues or
suspected issues to
+ [the issue tracker](#issues).
+ The sooner we resolve any problems, the fewer betas or release
candidates we will have to distribute before we are done.
+ (How do we know when we're done? -- When we run out of issues =:o) The
sooner we find them, the sooner we are done.)
+
+ - **Contribute [unit tests](kickstart.html#tests)**. The closer we get to
a release, the more we worry
+ about breaking something. The more tests we have, the more confident we
can be when applying patches.
+ Tests that prove that a pending issue is actually a defect are the most
welcome ones.
+ But we are eager for any and all tests for any and all features, even
those that still work =:0).
+
+ - **Review the list of issues** at [the issue tracker](#issues). If there
are any to which you can respond, please
+ do. If there any patches posted, feel free to test them your system,
report the results, and cast your vote
+ if they work.
+
+ - *Confirm an issue's category and status*. Newbies often post feature
suggestions or help-desk
+ questions as "bugs". This bloats the list of fixes we (apparently) need
to apply before the next
+ beta, making it hard to see the forest for the trees.
+ If an issue doesn't seem to be categorized correctly, exercise your best
judgment and change it.
+ If one ticket seems like a duplicate of another, go ahead and enter the
change.
+ Every modification to the ticket is echoed to the DEV list and
automatically subjected to peer review.
+ Err on the side of doing.
+
+ - Use the issue tracker to **vote for issues** you feel should be handled
first. If an issue on your
+ ballot doesn't include a patch, feel free to try coding one yourself.
(In a meritocracy, patches are
+ the only votes that matter.)
+ Dozens of developers have contributed code or documentation to Struts.
You can too =:0)
+
+ - **Answer questions on the user list**. The Committers only have a
limited amount of time to volunteer.
+ If Developers are supporting each other on the lists, the Committers
have more time to spend on the next
+ release.
+
+ - ### <a name="decides_help"></a>How can I help make the decisions?
+
+ 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 Apache Struts, 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 Struts 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](http://apache.org/foundation/how-it-works.html)
+ and the [Apache Struts Charter](bylaws.html). For more about project
infrastructure,
+ see "Project Maintenance and Resources" in the [Struts 1
wiki](http://wiki.apache.org/struts/).
![https://s3.amazonaws.com/github/ribbons/forkme_right_red_aa0000.png"](https://s3.amazonaws.com/github/ribbons/forkme_right_red_aa0000.png"){kind=link}