helping.fml

portal越来越流行了

                    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="#issues">JIRA issue
                    tracker.</a>
                </p>

            </answer>
        </faq>

        <faq id="contribute">
            <question>How can I contribute to the Pluto source
                code?</question>
            <answer>

                <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 seen an issue that needs a unit test to prove its
                    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 Pluto.
                    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>

            </answer>
        </faq>

        <faq id="documentation">
            <question>How can I contribute to the
                documentation?</question>
            <answer>
            	<p>
            	    The same way you contribute to the source code.  All
                documentation is generated using maven.

              </p>
            </answer>
        </faq>

        <faq id="release">
            <question>So when is the next release coming out?</question>
            <answer>

                <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 Pluto 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 Pluto,
                    then you should base your development on the release
                    build
                    of Pluto,
                    and keep an eye on what is coming down the pipeline.
                    This way you are at least forewarned and forearmed.
                </p>

            </answer>
        </faq>


        <faq id="decides_help">
            <question>How can I help make the decisions?</question>
            <answer>

                <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 Pluto,
                    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 Portals 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
                </p>

            </answer>
        </faq>

    </part>
</faqs>