jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "horwat" <Justyna.Hor...@Sun.COM>
Subject Re: [PROPOSAL] Management of Taglib Submission process
Date Fri, 10 Aug 2001 21:29:17 GMT
I really like Bay's proposal for taglib submission management. He has a lot
of good ideas. I've taken some of his ideas and incorportated them into a
more process oriented proposal. I wanted to create some infrastructure that
handles a new proposal when it is submitted making sure that it doesn't fall
through the cracks. I've also included what is hopefully the beginning for
review guidelines.

I liked Glenn's suggestion for tracking taglib submissions but I think it
could be done through the website itself much like the current news section.

I look forward to your feedback.

Thanks!

Justy

--------------------------------------------------------

Proposal for Management of Taglib Submission Process

1) Initiation of a Proposal

    When a proposal is submitted to the tomcat-dev list it is first reviewed
by the Proposal Manager. The Proposal Manager can be made up of one or more
people.

    The Proposal Manager's role is not to evalute the technical content,
that is up to the review process, but to be the first point of contact with
the submitter and provide immediate recognition of the proposal.  The
proposal will be reviewed by the proposal manager for well formedness and
verified that it follows the guidelines described on the website.

    The Proposal Manager can request for new drafts of the proposal if it
does not meet the guidelines outlined in the jakarta taglibs web site.

    Once the proposal meets these guidelines, it will be included in the
Proposals section of the jakarta taglibs main web page.

    The Proposals section of the main jakarta taglibs web page should
include the following information:
     - date of the proposal
     - contact e-mail of the person making the proposal (unless requested to
be withheld)
     - short description
     - link to a war of the doces
     - links to a war of the examples
     - links to zip of the source code

 As the proposal is reviewed, the names of the reviewers, their votes, and
the date will be added to the proposal.

2) Review and Approval

    After the proposal is added to the main jakarta taglibs web page it will
be up for review. All jakarta taglibs committers have a right to review a
proposal. They should review it based on the Tag Library Review and Approval
Process.

    A tag library needs 3 positive and no negative votes to be added as a
project to jakarta taglibs. A vote is defined as follows:

    a) +1    Want to include proposal as a project and am willing to support
contribute to the project
    b) +0    Want to include proposal as a project but not willing to commit
to contributing
    c) -0    Don't want to include proposal, but don't have compelling
enough reason to reject it outright
    d) -1    Don't want to include proposal as a project

    To be included as a project, a proposal needs 3 positive votes and no -1
votes. A negative vote requires an explanation. These voting rules are
similar to the generic jakarta voting rules with a slight adaptation to
account for the uniqueness of the jakarta taglibs project.

    Only one -1 vote is required to keep a proposal from becoming a project.

    If the proposal has not been voted on within 2 weeks of its submittal,
the Proposal Review Team will then review it. The Proposal Review Team is
made up of at least three jakarta taglibs committers who volunteered to
review proposals that have remained unreviewed for two weeks since the
initial submittal.

    The Review Team will have 1 week to review the proposal before voting on
it.

    Note that the Review Team is in place to keep proposals from falling
through the cracks and should not be relied on a regular basis.  It is every
committer's responsibility to review a proposal whenever possible.

    After a proposal has been voted on and is accepted, it needs 3 positive
votes to be accepted as a project.

    Once a proposal has been approved, it should be added as a project in
jakarta taglibs by the author. If the proposal was submitted by a
non-commiter, the current committers should vote whether to accept the
author as a committer. It would make sense for the author of the proposal to
be a committer responsible for their accepted library.


3) Publication

    Once a proposal has been approved, the proposal will be added to the
jakarta taglibs repository. It will then be removed from the Proposals
section of the website and moved to the Tag Library section.

4) Advancement

    The committers responsible for the project are responsible for the
advancement of library releases.


---------------------------------------
Tag Library Review and Approval Process

This process is used to rate and review a project proposal. The comments in
parenthesis are a only a guideline for making an evaluation.

A scale of 0 to 5 should be used in each category as follows:

    0:  Very poor (ie. non-existant documentation, code doesn't work,
doesn't follow set up guidelines, many modification necessary)
    1:  Poor (ie. documentation not complete, code unstable or doesn't work
right, some changes necessary)
    2:  Fair (ie. documentation poorly written, non-working examples, minor
changes necessary)
    3:  Good (ie. good documentation, working examples, code fairly well
written)
    4:  Very good (ie. complete documentation, great working examples, code
well written)
    5:  Excellent (ie. excellent documentation, excellent working examples,
code very well written, library meets or exceeds defined guidelines)

1) Defined Criteria

    The proposal should be reviewed in the following categories:

        a) Code Quality
         - is the code well written, good coding style
         - javadoc comments?
         - easy to follow
        b) Documentation
                - motivation for the tag library
         - use cases
         - clear description
        c) Examples
         - good coverage
         - easy to use and apply
        d) Uniqueness
         - avoids overlap with existing libraries
                    - if the overlap is too great, a merge with the existing
tag library should be considered
        e) Structure
         - follows well defined jakarta taglib structure


2) Vote Evaluation

   Add the vote total for all the categories together and divide by the
number of categories. This will give you the average score for the project.

   A positive score is one ranging between 3 and 5. The proposal is approved
as a project and a +1 or a +0 vote should be cast.

   If the average is less than 3 or if the proposal fails in a specific
category then the proposal may not be ready to be included as a project. If
this is the case, the reviewer can ask the person making the proposal to
revise the proposal in the deficient categories. A contingent -1 vote should
be cast. The contingency should be well outlined so the author can revise
the proposal and resubmit for a re-review.

   If the average is less than 3 or if the proposal fails in a specific
category and there is no room for improvement then a -1 vote with an
explanation of the vote should be cast.





Mime
View raw message