This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Push for Quality"

From OWASP
Jump to: navigation, search
(Changed intro to overview added Assessing a project section)
(Added prerequisites section)
Line 31: Line 31:
  
 
All existing projects and their current ratings are [http://www.owasp.org/index.php/Category:OWASP_Project here]. Any new OWASP project and its deliverables will be assessed based on the criteria below as well as any [http://www.owasp.org/index.php/Category:OWASP_Season_of_Code Season of Code] project. The goal is to eventually have all OWASP project deliverables, past and future, assessed under a version of this criteria. The initial set of assessment criteria was created for the OWASP Summer of Code 2008 and was designated version 1.0. The current version below was derived from version 1.0 and is version 2.0. Labelling any new criteria with a version number allows for graceful transitions to occur should any criteria change.
 
All existing projects and their current ratings are [http://www.owasp.org/index.php/Category:OWASP_Project here]. Any new OWASP project and its deliverables will be assessed based on the criteria below as well as any [http://www.owasp.org/index.php/Category:OWASP_Season_of_Code Season of Code] project. The goal is to eventually have all OWASP project deliverables, past and future, assessed under a version of this criteria. The initial set of assessment criteria was created for the OWASP Summer of Code 2008 and was designated version 1.0. The current version below was derived from version 1.0 and is version 2.0. Labelling any new criteria with a version number allows for graceful transitions to occur should any criteria change.
 +
  
 
'''Assessing a project'''
 
'''Assessing a project'''
Line 46: Line 47:
 
* Beta quality: The review will first be conducted by the project's reviewer (more on this below). After the reviewer completes the reviewer action items, the GPC will validate the project's assessment.  
 
* Beta quality: The review will first be conducted by the project's reviewer (more on this below). After the reviewer completes the reviewer action items, the GPC will validate the project's assessment.  
 
* Release quality: The two project reviewers will complete their action items (more on this below). After the reviews are complete, the Global Projects Committee and OWASP Board will validate the project's review.
 
* Release quality: The two project reviewers will complete their action items (more on this below). After the reviews are complete, the Global Projects Committee and OWASP Board will validate the project's review.
 +
 +
 +
'''Prerequisites for project assessment'''
 +
 +
 +
Depending on the quality level criteria, the project lead may have prerequisites before the project deliverable(s) can be assessed by the criteria below
 +
 +
* Alpha quality: No prerequisites.
 +
* Beta quality: 1 reviewer is required.
 +
* Release quality: 2 reviewers are required. Second review has special requirements.
 +
 +
 +
Notes on reviewers
 +
 +
* Ideally, the project lead will suggest project reviewer(s).
 +
* Ideally, reviewers should be an existing OWASP project lead or Chapter leader. 
 +
* If the project lead is unable to find the required reviewer(s), the Global Projects Committee can assist in identifying reviewers for the project.
 +
* It is recommended that an OWASP board member or Global Projects Committee member be the second reviewer on Release quality deliverables. The board has the initial option to review a project, followed by the Global Projects Committee.
 +
* The OWASP board reserves the right to deny the appointment of any reviewer.
 +
 +
 +
'''Tools Assessment Criteria'''

Revision as of 20:21, 30 March 2009

This is a DRAFT page still under review by the Global Projects Committee

This page is maintained by the Global Projects Committee to help assist Project Leaders with information about successfully running an OWASP Project. It will be updated from time to time, and changes will be discussed and announced on the OWASP-Leaders list.

Overview

OWASP created the project assessment criteria to define the quality levels for OWASP Projects with the purpose of evaluating all OWASP projects. The overall goal was to ensure that consistent quality levels are maintained by OWASP projects. This benefits both the external audience and those working on projects. The criteria allows the external audience to determine the quality of any OWASP project they are considering. For project members, it provides a method to measure the quality of their project in relation to other OWASP projects. Additionally, the criteria allows for excellent contributions to be recognized and projects which need further work to be identified.

Currently, OWASP projects fall into three primary categories:

  • Tools
  • Documents
  • Activities and Research


The Tools and Documents categories are easily understood. The Activities and Research category is less obvious and is used for projects which either have multiple sub-projects or have deliverables which fall into both the tools and documents category. Thus, Activities and Research can be used for parent projects that cover multiple smaller sub-projects. Some examples will make this clearer:

  • OWASP ESAPI
    • Java
    • .Net
    • PHP
    • ...
  • OWASP Guides
    • Testing Guide
    • Development Guide
    • Code Review Guide
    • ASDR (Application Security Desk Reference)
  • OWASP OpenPGP Extensions for HTTP - Enigform and mod_openpgp


All existing projects and their current ratings are here. Any new OWASP project and its deliverables will be assessed based on the criteria below as well as any Season of Code project. The goal is to eventually have all OWASP project deliverables, past and future, assessed under a version of this criteria. The initial set of assessment criteria was created for the OWASP Summer of Code 2008 and was designated version 1.0. The current version below was derived from version 1.0 and is version 2.0. Labelling any new criteria with a version number allows for graceful transitions to occur should any criteria change.


Assessing a project

Any OWASP project will consist of two critical pieces:

  • the project's OWASP Wiki page
  • one or more project deliverables

Each of these pieces will be have different methods with which they are reviewed. For OWASP project wiki pages, please see the Project Wiki Pages section of the Guidelines for OWASP Projects.


For project deliverables, OWASP has established the assessment criteria with three designations of quality: Alpha, Beta and Release. As project deliverables move up the quality ladder from Alpha to Beta and finally to Release quality, the amount of rigor required increases. In general, the project lead will determine the goal quality level of their project and work towards fulfilling the criteria for that level. Once a project lead has completed the prerequisites and criteria for the goal level, they request that their project be reviewed. The level will determine who and how those reviews occur.

  • Alpha quality: The review consists of the Global Project Committee (GPC) verifying that the project pre-assessment check-list is complete. Apha projects are the most free and open since anyone with solution to an application security problem can propose a new OWASP project. Alpha is where all new projects begin.
  • Beta quality: The review will first be conducted by the project's reviewer (more on this below). After the reviewer completes the reviewer action items, the GPC will validate the project's assessment.
  • Release quality: The two project reviewers will complete their action items (more on this below). After the reviews are complete, the Global Projects Committee and OWASP Board will validate the project's review.


Prerequisites for project assessment


Depending on the quality level criteria, the project lead may have prerequisites before the project deliverable(s) can be assessed by the criteria below

  • Alpha quality: No prerequisites.
  • Beta quality: 1 reviewer is required.
  • Release quality: 2 reviewers are required. Second review has special requirements.


Notes on reviewers

  • Ideally, the project lead will suggest project reviewer(s).
  • Ideally, reviewers should be an existing OWASP project lead or Chapter leader.
  • If the project lead is unable to find the required reviewer(s), the Global Projects Committee can assist in identifying reviewers for the project.
  • It is recommended that an OWASP board member or Global Projects Committee member be the second reviewer on Release quality deliverables. The board has the initial option to review a project, followed by the Global Projects Committee.
  • The OWASP board reserves the right to deny the appointment of any reviewer.


Tools Assessment Criteria