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 "Project Reviews Guideline"

From OWASP
Jump to: navigation, search
(→‎Documentation)
(→‎How can you contribute)
Line 31: Line 31:
  
 
This is how you can help us evaluate the health of a project
 
This is how you can help us evaluate the health of a project
−
*Check the criteria that applies for each project type here:
+
*Check the criteria that applies for each project (see tabs for criteria)
−
*Follow the criteria and do some research
+
*Follow the criteria with the following steps:
 +
-Visit the projects inventory page
 +
-Click on the project wiki page you want to review
 +
-Check the history /last updated date and by who
 +
-Check the amount of views on the bottom of the page
 +
-Read the content and click all hyperlinks available, are there any broken?
 +
-Visit the repository's project (like Github)project and check the wiki, issues, branches
 +
 
 
*Create a new Google sheet  
 
*Create a new Google sheet  
 
*Fill in the sheet. Try to add to your report also some print screens, hyperlinks, in other words how did you came to the conclusions and findings in the comments sections. It is very important that you can sustain the findings provided in your report sheet   
 
*Fill in the sheet. Try to add to your report also some print screens, hyperlinks, in other words how did you came to the conclusions and findings in the comments sections. It is very important that you can sustain the findings provided in your report sheet   

Revision as of 12:58, 21 August 2015

OWASP Project Header.jpg

Purpose

Project Reviews is a process within OWASP to help evaluate the health and quality of OWASP projects. The evaluation is based on a defined criteria which attempts to find out the progress and at which stage development the projects are.

This is the original plan https://www.owasp.org/index.php/Proposal_Project_Review_QA_Approach

Background

Projects are divided in 3 main categories:

  • Code
  • Tools
  • Documentation

These are the 3 main development classifications

  • Incubators
  • LAB
  • Flagship


How can you contribute

We need regular or season reviewers to help us evaluate projects.

This is how you can help us evaluate the health of a project

  • Check the criteria that applies for each project (see tabs for criteria)
  • Follow the criteria with the following steps:

-Visit the projects inventory page -Click on the project wiki page you want to review -Check the history /last updated date and by who -Check the amount of views on the bottom of the page -Read the content and click all hyperlinks available, are there any broken? -Visit the repository's project (like Github)project and check the wiki, issues, branches

  • Create a new Google sheet
  • Fill in the sheet. Try to add to your report also some print screens, hyperlinks, in other words how did you came to the conclusions and findings in the comments sections. It is very important that you can sustain the findings provided in your report sheet
  • share the sheet through the Project task force mailing list

Quality of a Code/Tool projects: This kind of evaluation requires more work. It is necessary to download and install the project. The criteria to evaluate the minimum quality of a project is very simple:

For Code and Tools

For projects holding Flagship status, we closely monitor their health every 6 months on the following, among other key indicators:

  • Can the project be built correctly?
  • Does the project has any activity(commits) in the last 6 months?
  • Does the project had any releases in the last 6 months?
  • Has the project leaders updated his wiki or website to reflect latest releases?

For Documentation

For this part, we are working on the development of an adequate assessment criteria The following is a draft of the new process proposal: [Proposal for Reviewing OWASP Document projects]


Presentation

https://soundcloud.com/owasp-podcast/owasp-project-reviews-with-johanna-curiel

Team Project Review

  • Johanna Curiel
  • Timo Goosen
  • Minur
  • Abbas Naderi

Support staff: Claudia.Aviles-Casanovas

Related Projects


Openhub

About the Black Duck Open Hub

The Black Duck Open Hub (formerly Ohloh.net) is an online community and public directory of free and open source software (FOSS), offering analytics and search services for discovering, evaluating, tracking, and comparing open source code and projects. Open Hub Code Search is free code search engine indexing over 21,000,000,000 lines of open source code from projects on the Black Duck Open Hub.

Use Openhub to have an overview of OWASP code and tools activity levels


Quick Download

  • Link to page/download

Email List

Project Email List

News and Events

  • [20 Nov 2013] News 2
  • [30 Sep 2013] News 1


In Print

This project can be purchased as a print on demand book from Lulu.com


Classifications

New projects.png Owasp-builders-small.png
Owasp-defenders-small.png
Cc-button-y-sa-small.png
Project Type Files CODE.jpg
  • Does the project have a publicly accessible bug tracking system established, and source code repository?
  • Does the project include online documention built into the tool?
  • Does the project include build scripts that facilitate building the application from source?
  • Does this project have an easy to use installer (Goal: Fully automated installer) (or stand alone executable version)?
  • Is the tool/deliverable user friendly and easy to use?

https://docs.google.com/spreadsheets/d/1upIyG0L-P-myUM6EPg0aJmCTDvJrdqaVdnjdNBME9is/edit?usp=sharing

  • Does the project have a publicly accessible bug tracking system established, and source code repository?
  • Does the project include online documentation built into the library?
  • Does the project include build scripts that facilitate building/adding to the application from source?
  • Does this project have an easy to use installer (Goal: Fully automated installer) (or stand alone executable version)?
  • Is the library/deliverable user friendly and easy to use?

https://docs.google.com/spreadsheets/d/1upIyG0L-P-myUM6EPg0aJmCTDvJrdqaVdnjdNBME9is/edit?usp=sharing

For documentations we use the health criteria:

Does it meet quality expectations?

  • Does the project have a relevant project summary that can be found on the OWASP Project wiki page?
  • Does the project have a relevant project Roadmap that can be found on the OWASP Project wiki page?
  • Does the project have a good track record of resolving issues and answering questions from project consumers?

Does it follow OWASP Project best practices?

  • Does the project use an appropriate Community Friendly License?
  • Are project deliverables, information, and releases readily available and accessible to the public?
  • Do the project leaders and contributors perform their duties in accordance to applicable laws?

Does it support the OWASP mission and objectives?

  • Do the project leaders and contributors treat everyone with respect and dignity?
  • Is the project vendor neutral?
  • Is the project free and open and not-for-profit?

Does the project have one accepted OWASP reviewed deliverable on record within the new project’s infrastrucutre?

https://docs.google.com/spreadsheets/d/1upIyG0L-P-myUM6EPg0aJmCTDvJrdqaVdnjdNBME9is/edit?usp=sharing

PROJECT INFO
What does this OWASP project offer you? 		RELEASE(S) INFO
What releases are available for this project?
what is this project?
Name: N/A
Purpose: N/A
License: N/A
who is working on this project?
Project Leader(s): N/A
how can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation:
Mailing list: N/A
Project Roadmap: Not Yet Created
Key Contacts
  • Contact the GPC to contribute to this project
  • Contact the GPC to review or sponsor this project
current release
pending
last reviewed release
pending


other releases

Retrieved from "https://wiki.owasp.org/index.php?title=Project_Reviews_Guideline&oldid=199347"