DrupalCon Baltimore: 161 sessions, many voices, infinite possibilities. Earlybird rate ends Friday.
Why should this issue be prioritized:
Amendments to the project applications process will unblock significant roadblocks to on-boarding new contributors, and remove a long-standing pain point for new entrants to the Drupal community.
Summary of Proposal (500 words or less):
After numerous false starts in the attempt to revamp the existing project applications process for obtaining permission to create ‘full projects’ on Drupal.org (largely due to a lack of clarity around governance and ownership of decision making surrounding the issue), the Technical Working Group coordinated with the Drupal.org Software Working Group and Drupal Security Team to come up with a proposed ‘next step’ for the project applications process. The proposal, outlined in, attempts to strike a balance between removing roadblocks to contribution for new contributors, and maintaining the community’s reputation for high standards of quality with regards to both code and security coverage for contributed projects listed on Drupal.org.
A proposed implementation plan is currently being circulated for comments amongst the TWG and Security team. Constructive comments and feedback welcome. https://docs.google.com/document/d/1eaI0Jq5CIVClCHv4uAxbJVHky5twPkWOqJ-A...
Constraints on the Solution
- We need to remove the gate to new contribution entirely - not just kick the can to a particular elevated role, or a specific limit on the # or kind of releases a new contributor is allowed.
- We need to continue to send strong signals about security coverage to users evaluating whether to use modules from Drupal.org.
- Follow-up: We need to find ways to preserve the value collaborative code review, through changes to Project Discovery to provide signals about code quality, and by providing incentives and credit for review.
After much discussion among many parties, including: @kattekrab, @dries, @mlhess and the security working group, myself, and users who have commented in these issues - we have found a solution. This is based on the initial proposal and work put together by @jthorson, adjusted to meet the above constraints more strongly.
Solution: High Level overview:
- The git user role (which any confirmed user can get by agreeing to the terms) will be able to:
- Create any number of projects (we will need a better policy for abundant namespaces)
- Create any releases for those projects
- All new projects will have a new option to opt in to security team coverage.
- Those that do not, will get a warning message on the project page and on the update status page for their sites. (this will require core updates for the update status)
- A role is required to opt in to security team coverage. We can repurpose the “git vetted user” role to “Opt into security team coverage”
- For now, to get the new “Opt into security team coverage” role, we will use basically the current project application process - however instead of being a gate on new project contribution, it is only a gate on participating in security team coverage.
- Because this opt-in process is now decoupled from the project creation/release process and is wholly in the domain of security coverage it can be replaced by a coding standards quiz or whatever the SecWG decides will best manage their work, sometime in the future.
Solution: User stories/issues:
Phase 1: Preserve the signals about project that give Drupal its security reputation:
- Mass update all existing full projects with stable releases to indicate they are 'covere'd ^^ in the new field
- Allow security team members to update the security advisory coverage field on projects
- , needs backport to D7
Phase 2: Set up the opt-in process
<- security team can set up their opt in process to receive that
- This is an evolution of what was originally planned in:
- Allow node owners of projects with the 'May opt-in...' role to update the advisory coverage field to opt-in.
Phase 3: Open the gates!
- Allow git-users to create full projects and releases* <-- this opens the gates
- Update all appropriate documentation
Phase 4: Project quality and code review incentives <-- even after the gates are open these have value!
- (Needs more specific user stories generated)
Drupal Association Liaison(s):
DA has prioritized time in Q1 2017
Long term support:
The DA and security team have agreed to support the process outlined in the high-level overview/user stories above
Meta / background
'Value Add' tasks
Long term 'value add' tasks to consider
- Introduce Automated Scans for security and coding style
- Display scan results on project pages
- Create an 'admin override' for webmasters to bypass false negative scan results blocking project promotion - adapt existing process
- Add check on scan results to the project promotion process