Dear IOOS Marine Life community member,
Thank you for taking the time to consider making a contribution to the repository. IOOS Marine Life data are developed by and for a broad community, and your contributions about datasets, tasking, and user stories are key to the IOOS Marine Life Data Network's success. This set of guidelines provides a brief overview of the practices and procedures that should be used in fixing, updating, or adding to this repository.
These contribution guidelines are designed to outline the usage of this repository and make it easy for others to contribute. They are intended to support open communication, data management, and scientific advancement as it relates to the IOOS Marine Life Program. If at any time you have questions, ask for help. Your contribution is valuable and the community will be happy to give a hand.
As this is an IOOS GitHub repository, the IOOS GitHub Code of Conduct applies. You can view this Code of Conduct here.
This repository is meant to include many different types of issues as they relate to the Marine Life Data Network. This includes but is not limited to:
- Marine Life Data Network (MLDN) specific tasking for the IOOS Marine Life Program Office and affiliated contractors
- Information about datasets to be mobilized into the MLDN ecosystem
- Long term planning for the MLDN
- User stories that provide insight into future improvements of the MLDN
These tasks are outlined in issues. If appropriate, related issues can be organized under Milestones so the progress toward their completion can be tracked. Anyone is free to submit an issue to the MLDN repository.
- Use the approprate issue template. There are different issue templates in the repository that correspond to the different issue types. Use the one that most closely corresponds with the issue you are submitting.
- Task-specific issues should be discrete and non-recurring. When submitting a task-specific issue, try to scope it so that it is a discrete task that can be marked complete. If it is a task that will repeat, try to word the request so it is specific. As an example, "Create and update public release notes for ATN and MBON portals" could be re-scoped to "Create release notes for ATN portal release version 1.1.1". If you are unsure how to do this but still want to make a request, submit the issue, and MLDN community members can help narrow the scope of the issue.
- Keep descriptions and discussions focused on the task. The descriptions and discussions within issues should be focused on what the task is and who is requesting the activity. Limit references to organizations/entities unless absolutely necessary, the moderators will use the
assignee
feature within GitHub issues to identify/notify appropriate staff.
- Keep descriptions and discussions focused on the task. The descriptions and discussions within issues should be focused on what the task is and who is requesting the activity. Limit references to organizations/entities unless absolutely necessary, the moderators will use the
- A given proposal should be discussed as one issue. It shouldn't fork or be superseded by another one, unless that reflects what has happened to the proposal. This is so it is easy to trace the discussion that led to a given agreed proposal.
- In general, issues should be used for discussion of proposed changes and pull requests should be used for review of agreed upon changes. In other words, if the content or concept of what is being proposed needs to be vetted by the community it should be vetted in an issue. If the proposal is non-controversial (such as a typo correction) or has been agreed to in concept in an issue, then detailed review of the text may take place in a pull request. Practically all changes should be documented and discussed in an issue and fixed in a related pull request.
- Use labels on issues and pull requests. After an issue is created, please add the relevant labels from the label dropdown menu.
- Role of the MLDN Moderators. Each issue should have a moderator who guides the discussion through the change process and summarises it occasionally. MLDN Moderators (currently, @MathewBiddle and @laurabrenskelle) will review comments on issues and update the initial description as appropriate. This will make it easier to understand what consensus was reached in the comments without reading the entire thread after the fact.
To propose a change to a document in the repository, please create a fork of the repository, make your changes, and submit a pull request for review. This allows better tracking of the changes that have been made. Further information about pull requests can be found at https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork.
Issues relating to specific tasking or long term planning may be moved by the IOOS Marine Life team to the Marine Life Data Network Project. This project functions like a kanban board with swim lanes for No Status (or backlog), ToDo, Blocked, In Progress, and Done.
Any member of the MLDN may move a task from To Do to In Progress as they begin work on it. However, only the Product Owner (@MathewBiddle) will mark issues as Done on the project board after reviewing the completion criteria to determine if it has been satisfied.
For each issue, an assignee
will be assigned, either by self assignment or through agreement within the issue. The assignee
is responsible for executing the effort and/or reporting on the progress of that effort. For more information about assignees
see the GitHub documentation.
Process for moving issues in the project board:
No status
->todo
decided during monthly meetings. Must haveassignee
determined at this point.Todo
->in progress
determined by assigneeIn progress
->done
determined by IOOS POIn progress
->blocked
decided by IOOS PO.