What not to release¶

• Use-case specific features (such as information no one else cares 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 properly generalized and abstracted.
  • Ensure that client information is removed from code.

Recommendation¶

An individual user (such as an architect or developer) releases to Drupal.org.

• Team should select who should own the module based on contribution to its creation and ability or 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.
  • Can make use of Drupal.org packaging and testing bots.
• Drawbacks
  • Organization does not have ownership of the module.

Alternatives¶

Organization ownership on Drupal.org

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 supported on Drupal.org; requires help from Drupal Association staff.

Releasing on GitHub with Drupal.org project page

• Benefits
  • Organization ownership is guaranteed.
  • GitHub project flows (such as pull requests).
• Drawbacks
  • Frowned upon by Drupal.org and part of community.
• Considerations
  • Must issues be handled on Drupal.org, GitHub, or both?
    • Recommendation: Issues must be tracked on GitHub to integrate best with the workflow.