jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: [PROPOSAL] Management of Taglib Submission process
Date Sat, 11 Aug 2001 16:18:06 GMT
Agreed - I think Bay's proposal is good, along with putting on the web page
new taglibs under consideration and the use of buzilla. Also we should make
more use of the jakarta-taglibs-sandbox as a collaborative area that we can
work together on new submissions and so forth.

Maybe we could put new submissions straight into the sandbox (assuming
licence is OK) while the initial evaluation is done? Then once the early
wrinkles are ironed out we can vote for it to go into the main repository?


----- Original Message -----
From: "horwat" <Justyna.Horwat@Sun.COM>
To: <taglibs-dev@jakarta.apache.org>
Cc: <bayard@generationjava.com>
Sent: Friday, August 10, 2001 10:29 PM
Subject: Re: [PROPOSAL] Management of Taglib Submission process

> I really like Bay's proposal for taglib submission management. He has a
> 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
> handles a new proposal when it is submitted making sure that it doesn't
> 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
> 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
> by the Proposal Manager. The Proposal Manager can be made up of one or
> 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
> 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
> 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
> 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
> 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
> contribute to the project
>     b) +0    Want to include proposal as a project but not willing to
> 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
>     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
> 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
> committer's responsibility to review a proposal whenever possible.
>     After a proposal has been voted on and is accepted, it needs 3
> 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
> 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
> 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
> right, some changes necessary)
>     2:  Fair (ie. documentation poorly written, non-working examples,
> changes necessary)
>     3:  Good (ie. good documentation, working examples, code fairly well
> written)
>     4:  Very good (ie. complete documentation, great working examples,
> well written)
>     5:  Excellent (ie. excellent documentation, excellent working
> 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
> 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
>    A positive score is one ranging between 3 and 5. The proposal is
> 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.
> 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
> 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.

Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

View raw message