Open Source Contributions

What not to release

Use-case specific functionality (i.e., stuff no one else will really care about)
- When in doubt, release
Confidential or security sensitive information
- Definitions will depend upon applicable NDA or security agreements

What to release

Patches to core or contrib
- Should always be contributed, if appropriate for public release
- Make use of organization crediting
Modules
- Ensure that these are propery generalized / abstracted
- Ensure that client information is removed from code

Recommendation

An individual user (e.g., architect or developer) releases to drupal.org.

Team should select who should own the module based on contribution to its creation and abilty/interest in on-going ownership
Ensure that maintainer transitioning is included in the process for off-boarding of staff
Make use of organization crediting
Benefits
- Greater community visibility
- Able to make use of D.O packaging and testing bots
Drawbacks
- organization does not have ownership of the module

Alternatives

Organization ownership on D.O

Create a drupal.org account to represent the organization. Use this account to maintain the project.

Benefits
- Organization cannot lose control of the module
- Can serve NDA processes
drawbacks
- Organization users are not really supported on D.O; requires assistance from Drupal Association staff

Releasing on GitHub with D.O project page

Benefits
- Organization ownership is guaranteed
- GitHub project flows (Pull Requests, etc.)
Drawbacks
- Frowned upon by D.O and part of community

Considerations
- should issues be handled on D.O, GitHub, or both?
  - recommendation: issues should be tracked on GitHub to integrate best with the workflow