Contributing

Note

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119

The DMP Roadmap project team is always eager to hear about new ideas for enhancing our shared system. We welcome any and all feedback and are interested in engaging with you to help us build the next generation of data management planning software.

Report issues

An easy and valuable way to help out is by simply letting us know about any issues you encounter while using the system. We always test changes made to the system but, as with any piece of software, there will be the occasional bug that slips by our defenses.

Please take a moment and look through the list of existing GitHub Issues before adding a new one. Someone else may have already reported the same issue. If so, add a comment and/or screenshot to provide additional details (this will help us prioritize the issue). The GitHub Issues page provides a search box and labels/tags that you can use to narrow down the list to see if something has already been reported.

If you don't see the issue listed then please create a new one. Be as descriptive as possible and outline the steps we can take to recreate the problem. For example: "I logged into the system as an organizational user, clicked edit plan (for plan X that was based on the NSF template) and got the following error message ...". Screenshots are also extremely helpful.

Warning

Be sure you have removed any sensitive information or Personally Identifiable Information (PII) before submit your issue

You do not need to apply any label.

Please note that the team has limited time and resources and so must prioritize the backlog of open issues and enhancement requests accordingly.

Share your ideas and suggest new features

The DMP Roadmap team welcomes your ideas for new enhancements and/or ways that we can integrate our tool into other systems. Your idea does not necessarily have to be fully formed. You can simply add a new issue to our GitHub Issues list. You must not apply any label.

Please take a moment and look through the list of existing GitHub Issues before adding a new one. If someone has already contributed a similar idea, feel free to add a comment to that issue and join the conversation even if it's just to help promote the idea.

Translations

The DMP Roadmap team is looking for help with translating the system to other languages. Currently, we have translations for English, French, German, Spanish, Finnish, and Portuguese(Brazil). We use the ISO 639-1 standard codes for languages.

Anyone can contribute translations for this system via:

• Our translation portal (see the translation Wiki page for more information)
• By manually updating/adding translation files and sending us a Pull Request (see the app.po file instructions for more information)

Improve documentation

All of the documentation for the DMP Roadmap project can be found on our Wiki. If you discover that something is missing or if any of the documentation appears to be incorrect or out of date, please let us know.

For corrections or new contributions, please submit a new [GitHub Issue](GitHub Issues) and be sure to use the 'documentation' label to help us categorize and identify the problem. If you're providing new documentation please note that your content is new and where it should appear within the Wiki. Specify the URL of the Wiki page that the correction applies to if possible.

Writing code

The DMP Roadmap team is always interested in collaborating with other developers. We welcome contributions of all types: features, bug fixes, performance improvements, and documentation updates. Coding Conventions](https://github.com/DMPRoadmap/roadmap/wiki/Coding_Conventions) and Testing Conventions are important because they ensure consistency, readability, and maintainability of code. Be sure to familiarise yourself with them before pushing back your contributions. If you would like to contribute to the project, please follow these steps:

• Find or create an issue

  • Comment on the GitHub issue you’d like to work on.
  • If no issue exists, follow the Report issues guidelines to create one. Describe what you plan to do as this avoids duplicate work and helps maintainers track contributions.

• Fork/update your repository (if you have not already). For the repository o if you already have a fork, sync/rebase it so that it is up to date with the latest main branch of this project.

• Create a new branch in your fork. This keeps your changes isolated and allows you to keep pulling updates from main.

  • Branches SHOULD be short-lived and focused on a single feature or fix.
  • Write clean, testable code.
  • Add or update unit/integration tests if relevant.
  • Before opening your PR, you
    • MUST merge/rebase changes from upstream main into your branch as needed.
    • MUST check your work against the Pull Request Checklists below

• Open a Pull Request (PR) from your branch to upstream main. In your PR description, include:

  • Related issue numbers (e.g., “Related to #42”) You MUST NOT use auto-closing keywords (e.g., “Fixes #42”), since releases are coordinated separately.
  • A summary of your changes
  • Any caveats, limitations, or follow-ups
  • If the change is urgent, explain why

The project team will review your changes and provide feedback.

Pull Request Checklists

Checklist for changes to a database table and/or its corresponding model

• Did you include the appropriate database migration? > rails g migration AddTwitterIdToUsers
• Did you update/add the Unit tests?
• Did your change require you to transform data? For example moving data from one field to another like moving users.organisation_id to a join table called users_organisations. If so, did you include a rake task to help others migrate their data over to the new model (along with instructions)?
• Does the schema.rb include the changes?
• Did you remember to update the seeds.rb file to reflect the change?

Checklist for changes to a controller

• Did you update/add the Functional tests?
• Did you update/add the Routing tests (if applicable)?
• Did you update the corresponding view(s)?
• Did you include any updates/additions to localisation text config/locales/pot file?

Checklist for changes to a view

• Did you include any updates/additions to localisation text config/locales/pot file?
• Did you update the corresponding controller?
• Did you manually test the change in multiple browsers?
• Did your change require modifications to the CSS, JS or image files? If so did you include them in your branded file locations or in the core system files? For example: lib/assets/javascripts is the default javascript directory. app/assets/javascripts are specific to your local installation. (See Branding for more information)