Google Git
Sign in
apache / struts-site / 56f3b08bc7780019c769eed45d9d80050018f567 / . / content / helping.html
blob: e45676612e3153c957f53b996737bf706e02df44 [file] [log] [blame]
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8"/>
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
<meta name="Date-Revision-yyyymmdd" content="20140918"/>
<meta http-equiv="Content-Language" content="en"/>
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<title>Helping</title>
<link href="//fonts.googleapis.com/css?family=Source+Sans+Pro:300,400,600,700,400italic,600italic,700italic" rel="stylesheet" type="text/css">
<link href="//netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css" rel="stylesheet">
<link href="/css/main.css" rel="stylesheet">
<link href="/css/custom.css" rel="stylesheet">
<link href="/highlighter/github-theme.css" rel="stylesheet">
<script src="//code.jquery.com/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" class="github-ribbon">
<img style="position: absolute; right: 0; border: 0;" src="https://s3.amazonaws.com/github/ribbons/forkme_right_red_aa0000.png" alt="Fork me on GitHub">
</a>
<header>
<nav>
<div role="navigation" class="navbar navbar-default navbar-fixed-top">
<div class="container">
<div class="navbar-header">
<button type="button" data-toggle="collapse" data-target="#struts-menu" class="navbar-toggle">
Menu
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a href="/index.html" class="navbar-brand logo"><img src="/img/struts-logo.svg"></a>
</div>
<div id="struts-menu" class="navbar-collapse collapse">
<ul class="nav navbar-nav">
<li class="dropdown">
<a data-toggle="dropdown" href="#" class="dropdown-toggle">
Home<b class="caret"></b>
</a>
<ul class="dropdown-menu">
<li><a href="/index.html">Welcome</a></li>
<li><a href="/download.cgi">Download</a></li>
<li><a href="/releases.html">Releases</a></li>
<li><a href="/announce-2021.html">Announcements</a></li>
<li><a href="http://www.apache.org/licenses/">License</a></li>
<li><a href="https://www.apache.org/foundation/thanks.html">Thanks!</a></li>
<li><a href="https://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
</ul>
</li>
<li class="dropdown">
<a data-toggle="dropdown" href="#" class="dropdown-toggle">
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>
<li class="divider"></li>
<li><a href="https://cwiki.apache.org/confluence/display/WW/Migration+Guide">Version Notes</a></li>
<li><a href="https://cwiki.apache.org/confluence/display/WW/Security+Bulletins">Security Bulletins</a></li>
<li class="divider"></li>
<li><a href="/maven/project-info.html">Maven Project Info</a></li>
<li><a href="/maven/struts2-core/dependencies.html">Struts Core Dependencies</a></li>
<li><a href="/maven/struts2-plugins/modules.html">Plugin Dependencies</a></li>
</ul>
</li>
<li class="dropdown">
<a data-toggle="dropdown" href="#" class="dropdown-toggle">
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 class="divider"></li>
<li><a href="/getting-started/">Getting Started</a></li>
<li><a href="/security/">Security Guide</a></li>
<li><a href="/core-developers/">Core Developers Guide</a></li>
<li><a href="/tag-developers/">Tag Developers Guide</a></li>
<li><a href="/maven-archetypes/">Maven Archetypes</a></li>
<li><a href="/plugins/">Plugins</a></li>
<li><a href="/maven/struts2-core/apidocs/index.html">Struts Core API</a></li>
<li><a href="/tag-developers/tag-reference.html">Tag reference</a></li>
<li><a href="https://cwiki.apache.org/confluence/display/WW/FAQs">FAQs</a></li>
<li><a href="http://cwiki.apache.org/S2PLUGINS/home.html">Plugin registry</a></li>
</ul>
</li>
<li class="dropdown">
<a data-toggle="dropdown" href="#" class="dropdown-toggle">
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><a href="/contributors/">Contributors Guide</a></li>
<li class="divider"></li>
<li><a href="/submitting-patches.html">Submitting patches</a></li>
<li><a href="/builds.html">Source Code and Builds</a></li>
<li><a href="/coding-standards.html">Coding standards</a></li>
<li><a href="https://cwiki.apache.org/confluence/display/WW/Contributors+Guide">Contributors Guide</a></li>
<li class="divider"></li>
<li><a href="/release-guidelines.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://gitbox.apache.org/repos/asf?p=struts.git">Source Repository</a></li>
<li><a href="/updating-website.html">Updating the website</a></li>
</ul>
</li>
<li class="apache"><a href="http://www.apache.org/"><img src="/img/apache.png"></a></li>
</ul>
</div>
</div>
</div>
</nav>
</header>
<article class="container">
<section class="col-md-12">
<a class="edit-on-gh" href="https://github.com/apache/struts-site/edit/master/source/helping.md" title="Edit this page on GitHub">Edit on GitHub</a>
<h1 class="no_toc" id="how-to-help-faq">How to Help FAQ</h1>
<ul id="markdown-toc">
<li><a href="#what-can-my-company-do-to-help-support-apache-struts" id="markdown-toc-what-can-my-company-do-to-help-support-apache-struts">What can my company do to help support Apache Struts?</a></li>
<li><a href="#patches" id="markdown-toc-patches">How do I create a patch?</a></li>
<li><a href="#issues" id="markdown-toc-issues">How can I report defects or suggest features?</a></li>
<li><a href="#contribute" id="markdown-toc-contribute">How can I contribute to the Struts source code?</a></li>
<li><a href="#documentation" id="markdown-toc-documentation">How can I contribute to the documentation?</a></li>
<li><a href="#release" id="markdown-toc-release">So when is the next release coming out?</a></li>
<li><a href="#release_help" id="markdown-toc-release_help">What can I do to help the next release along?</a></li>
<li><a href="#decides_help" id="markdown-toc-decides_help">How can I help make the decisions?</a></li>
</ul>
<ul>
<li>
<h3 id="what-can-my-company-do-to-help-support-apache-struts">What can my company do to help support Apache Struts?</h3>
</li>
</ul>
<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>
<ul>
<li>
<h3 id="patches">How do I create a patch?</h3>
</li>
</ul>
<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="highlighter-rouge"><div class="highlight"><pre class="highlight"><code> git diff Main.java &gt;&gt; patchfile.txt
</code></pre></div></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>
<ul>
<li>
<h3 id="issues">How can I report defects or suggest features?</h3>
</li>
</ul>
<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/~sgtatham/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>
<ul>
<li>
<h3 id="contribute">How can I contribute to the Struts source code?</h3>
</li>
</ul>
<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>
<ul>
<li>
<h3 id="documentation">How can I contribute to the documentation?</h3>
</li>
</ul>
<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="https://www.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>
<ul>
<li>
<h3 id="release">So when is the next release coming out?</h3>
</li>
</ul>
<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>
<ul>
<li>
<h3 id="release_help">What can I do to help the next release along?</h3>
<ul>
<li>
<p>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.)</p>
</li>
<li>
<p><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).</p>
</li>
<li>
<p><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.</p>
</li>
<li>
<p><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.</p>
</li>
<li>
<p>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)</p>
</li>
<li>
<p><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.</p>
</li>
</ul>
</li>
<li>
<h3 id="decides_help">How can I help make the decisions?</h3>
</li>
</ul>
<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="https://www.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>
</section>
</article>
<footer class="container">
<div class="col-md-12">
Copyright &copy; 2000-2018 <a href="http://www.apache.org/">The Apache Software Foundation </a>.
All Rights Reserved.
</div>
<div class="col-md-12">
Apache Struts, Struts, Apache, the Apache feather logo, and the Apache Struts project logos are
trademarks of The Apache Software Foundation.
</div>
<div class="col-md-12">Logo and website design donated by <a href="https://softwaremill.com/">SoftwareMill</a>.</div>
</footer>
<script>!function (d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (!d.getElementById(id)) {
js = d.createElement(s);
js.id = id;
js.src = "//platform.twitter.com/widgets.js";
fjs.parentNode.insertBefore(js, fjs);
}
}(document, "script", "twitter-wjs");</script>
<script src="https://apis.google.com/js/platform.js" async="async" defer="defer"></script>
<div id="fb-root"></div>
<script>(function (d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
js = d.createElement(s);
js.id = id;
js.src = "//connect.facebook.net/en_GB/all.js#xfbml=1";
fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>
</body>
</html>