GPTC Minutes 2008-12-16
Below is a summary of the OWASP Global Projects Committee meeting on 2008-12-16.
Return to Committee Page
Action Items from Meeting
- Agree on the project template for every project to use
- In particular, determine what needs to be on every project page, globally for OWASP
- Perhaps project “skeleton” page is a better term
- Base the discussion on what Paulo has created - See links # 1 and #2 below for examples.
- How to handle / divide agenda items within the committee's timeline (6 mo, 12 mo, 18 mo)
- Bring items to the next meeting and we will vote on them then
- The goal is to redefine the action plan for 2009 setting up specific goals
- Discussions will be on the mail list for now until some issues with the forum are worked out
- Next meeting scheduled: January 6th at 10 PM GMT
Other Issues Raised for Consideration
- Consider recording the Skype meetings in future
- Need to sort out the projects roles/responsibilities for
- Project Leaders
- Project Contributors
- Project Reviews
- Look at how others do this (Apache project, other code sponsorships – Google & Yahoo)
- How to close out the Summer of Code 2008
- How to handle past company sponsored projects which have been refreshed significantly. Examples include:
- Web Goat
- OWASP Testing Guide
New Items from Meeting
- SAMM is now under creative commons licensing
- SAMM (original) and a rewrite in progress will now be merged
- Current status can be seen at http://www.opensamm.org/Home.html
Links from the meeting
- Example of SoC Project Template
- Examples of new “streamlined” table
- Paulo's and Dinis' thoughts on a reviewers role
- Current committee page for agenda items, etc
- Examples of differing reviews from the SoC
- Google Spreadsheet from SoC about project completion
- Project Assessment Criteria
Unofficial Meeting Agenda
(AKA Matt Tesauro's prep notes for the meeting)
[Modified to include Pravir Chandra's late addition to the agenda items]
Agenda: (from OWASP.org)
To this end, the OWASP Global Projects Committee establishes the following agenda for the 2009 calendar year.
- Define Metrics: define metrics to measure OWASP Projects through various aspects such as quality, activity, usability, relevance, currentness, availability and popularity.
- Apply Metrics: to all existing OWASP Projects and determine the status for each project
- Incorporate Results: incorporate results and experiences during re-evaluation process to establish new categorizations for projects
- Create Metadata: create a defined set of project metadata to be captured for all OWASP Projects to facilitate organization and maintenance.
- Capture Metadata: capture all defined metadata for existing OWASP Projects
- Provide Repository: Provide a standardized, managed, OWASP-controlled repository for all OWASP Projects to facilitate a consistent manner to retrieve the latest versions of OWASP projects.
- Create Project Kit: Create a kit for new OWASP projects that includes standard graphic design elements such as OWASP logos, recommended color schemes, fonts, templates, etc. These elements should be used for both OWASP Tools and Documentation projects. In addition, consider creating human user interface guidelines for tools that use GUIs.
- Migrate Projects: Migrate existing projects to the OWASP Repository
- Revamp Project Site: the OWASP Project website to leverage the newly created metadata, metrics and centralized repository. Additionally, the OWASP Project website should allow for members of the OWASP community to suggest new project ideas.
- Rework Project page table: Re-work the X of Code table to incorporate the new metrics above
- Transition Process: Provide a transition process from X of Code to a proper project page
- Capture Metrics: Provide a method to capture and keep the metrics needed for a project in a way that doesn't interfere with marketing that project to its target audience(s)
- Template for Project Pages: Provide some sort of skeletal project page which contains a mixture of required, optional and free-form elements so that project pages are consistent (good for OWASP globally) while flexible enough to serve the project's audience (good for that project specifically). Basically expand what's here:http://www.owasp.org/index.php/How_to_Start_an_OWASP_Project
- Documentation Project Workflow: Research and define a workflow for documentation projects such that they can provide content for wiki, download, and printed matter in a way that minimizes effort.
Other items raised on OWASP Leaders List:
- Use of Forums vs. Mailmain Email list
- Skype calls vs Forum discussions vs Mailman – talk about what in which technology
- OWASP definition of Open Source?
- From Dave Wichers (Leaders list)Yes - I think the Global project community should help select the set oflicenses we support.I think Jeff might already have done this and its on the licenses page, butplease coordinate with him.-Dave
- Is http://www.owasp.org/index.php/OWASP_Licenses sufficient ? The text from that page is below:"All software, documentation, and other materials produced by The OWASP Foundation or any of its projects is licensed according to one of the approved FLOSS licenses, such as the GNU "Lesser" GNU Public License (LGPL), the BSD license, or the Creative Commons Attribution ShareAlike 3.0 license. For licensing questions, please contact us at email@example.com."
- New Projects
- Is the how to start an OWASP project on the Wiki sufficient?https://www.owasp.org/index.php/How_to_Start_an_OWASP_Project
- OWASP Proxy (Rogan)
- RSS for projects (from Leaders List)
- Mike Boberski suggested a RSS feed to track OWASP project globallyI would like to propose a new separate RSS feed that can be used to track OWASP project activity in general. Perhaps, tailored for a small specific set of event types, if existing tools supported this functionality.I would for example be interested in being notified using a feed when there is a new article for a project that I may not be monitoring closely but am interested in.
- Jason Li responded: Came up at summit for Web Site Working Group:I've often thought the same thing and I brought this up as a suggestion at the recent OWASP EU Summit (see https://www.owasp.org/images/8/8b/EUSummit08_OWASP_Web_Site_Working_Session_Suggestions.doc).The folks overseeing the OWASP Website project are working on this feature
- Matt Tesauro wonders – is this a semi-requirement for the starndardized repository? Should that be a consideration when we address that agenda item.
- Catpure time spent metrics (from Leaders List)
- Antonio Fontes suggested tracking time spend on projects during a lengthy thread on increasing memberships, the 60/40 program, etc:Your first challenge, at the leader level, I guess, is about getting people to clearly measure what is being done behind the scenes. When I go on the Code Review project page for example, I don't know how many hours were spent on it. This is something we all learn at school and that I experience on a daily basis at work: metrics make value. When I started working where I work now, I had to put the time/costs breakdown in the code review report to make people understand why the report wasn't delivered just 30 minutes after sending a 'CR' request to my office.When the OWASP gets people to understand what is 'behind' the scenes, donations should come right after. If they don't, I guess the OWASP would have to consider re-targetting its audience...
- Matt Tesauro ponders: An interesting and probably valuable metric but one that is very hard to capture. I certainly didn't for my Live CD SoC project.
- Asyncronous discussion request by Andrew Petukhov (time zone issues with Skype call)