Return-Path: Delivered-To: apmail-jakarta-taglibs-dev-archive@jakarta.apache.org Received: (qmail 35482 invoked by uid 500); 10 Aug 2001 21:31:13 -0000 Mailing-List: contact taglibs-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk Reply-To: taglibs-dev@jakarta.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list taglibs-dev@jakarta.apache.org Received: (qmail 35475 invoked from network); 10 Aug 2001 21:31:13 -0000 Received: from patan.sun.com (192.18.98.43) by h31.sny.collab.net with SMTP; 10 Aug 2001 21:31:13 -0000 Received: from shorter.eng.sun.com ([129.144.252.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29291; Fri, 10 Aug 2001 15:31:14 -0600 (MDT) Received: from wintermute (d-ucup02-124-232 [129.144.124.232]) by shorter.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA16702; Fri, 10 Aug 2001 14:30:59 -0700 (PDT) Message-ID: <041d01c121e4$781d70e0$6501a8c0@wintermute> From: "horwat" To: Cc: References: Subject: Re: [PROPOSAL] Management of Taglib Submission process Date: Fri, 10 Aug 2001 14:29:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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.