Information for: DEVELOPERS   PARTNERS

Open Source Contributions

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.