This is a meta issue for tracking the status of issues related to the https://groups.drupal.org/node/291343 blog post.

As issues are created, I'll be adding them here.

Implementation steps

1. Expose project shortname field on sandbox projects.

In Project 7.x-2.x, the project shortname field is stored in field_project_machine_name, on the content type ‘project’. By default, this uses the ‘machine_name’ widget type, which is rendered read-only when editing the project by setting the ‘#disabled’ property on the element.
On sandbox projects, this field is set to the node id by default.

Tasks:
#2034475: Determine if field_project_machine_name is referenced by any other code on a 'sandbox' project
#2034477: Remove the '#disabled' property on field_project_machine_name field widget
#2035179: Add a new validation routine to the 'edit project' form
#2035183: Add an additional 'submit' routine to the 'edit project' form
#2035185: Update the 'promote to full project' to use machine name instead of nid

2. Automated reviews.

The second key to this proposal is the implementation of automated git repository and code review tests, to ensure that code meets at least minimal requirements before it can be promoted out of the 'sandbox' state.

Tasks:
#2035187: UI Mockups demonstrating how to manually trigger automated reviews
#2035191: UI Mockups demonstrating display of automated review results for a project
#2035195: UI Mockups demonstrating how an admin would override automated test results
#2035199: Come up with a data structure for storing automated test results for a project
#2035203: Determine what endpoints will be responsible for executing the automated reviews
#2035207: Determine automated review workflows
#2035209: Implement the Automated Review endpoints
#2035211: Implement the Automated Review 'triggering' elements.
#2035213: Implement the Automated Review 'results' display elements
#2035221: Implement the Automated Review 'admin override' mechanisms
#2035223: Implement the Automated Review 'automated' workflows

3. Packaging restrictions

The third component of this proposal is restricting users from creating 'stable' releases unless they have been granted the 'git vetted user' role.

Tasks:
#2035235: Add a permission for creating stable releases, and grant to “git vetted” users
#2035237: Hide the 'create releases' link if user can not create releases

4. Only mark 'stable' release patterns as 'green'.

To encourage the creation of 'stable' releases for projects, change the default colors on the project release table output, and only mark releases matching the 'stable' release pattern as green.

Tasks:
#2035241: UI Mockups demonstrating release table with only 'stable' as green.
#2035243: Ensure/add css classes based on release pattern to the project release table

5. Provide notices on the project pages for non-vetted users and/or security advisory coverage (based on stable/unstable release types).

Tasks:
#2035277: Draft text for security advisory coverage messages
#2035279: Create UI mockups containing the warning messages, considering both Project and Release pages.
#2035281: Implement the Project and Release page warning notices