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.
Drupal Association Liaison(s):
Long term support:
Meta / background
Short term tasks
Short term 'Value Add' tasks
Long term tasks
- 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