Skip to content

Latest commit

 

History

History
43 lines (28 loc) · 3.49 KB

ways_of_working.md

File metadata and controls

43 lines (28 loc) · 3.49 KB
Raw

MapReader Ways of Working

This document outlines expectations and responsibilities with regard to working on the project.

Commitments

All MapReader project members commit to:

  • making the implicit explicit by clearly documenting their work
  • following the contribution guidelines and ensuring they are kept up to date
  • recording any new updates, exceptions or useful knowledge in project management and core documents needed to facilitate collaboration
  • dedicating their time and expertise in fixing open issues either directly via GitHub or providing mentorship and support to community members and project contributors
  • provide feedback on MapReader by opening issues in the MapReader GitHub repo
  • documenting and sharing any conversation from closed spaces (such as email, Slack or 1:1 meeting) in a GitHub issue that could be useful for the community or community members in enabling their work in MapReader

Communication

You can reach out to any member by tagging them on GitHub issues or Pull Requests.

You can reach the lead investigators of the project through their preferred way of communication:

Project management

The project members triage on open issues, review Pull Requests or address any questions raised on GitHub asynchronously. As most members do not work full time on MapReader, it might take some time until your query or contribution is addressed - especially if expert knowledge is needed. Don't be afraid to nudge if they've not replied after a few days! 💖

Issues & Pull Requests

Project members will:

  • monitor open issues and Pull Requests on the project's GitHub repository to identify if feedback, comment or connections can help address any concern or build on any suggested ideas/features.
  • whenever possible, post about the issues and Pull Requests in public forums (newsletter, Slack, Twitter) to facilitate participation from new members in the community.
  • review or assign a reviewer to open Pull Requests for review. This should be taken as an opportunity to connect contributors with specific interests, availability or technical skills that could be useful for the ongoing work.
  • connect issues and Pull Requests where possible (for example, by mentioning 'Fixes #[issue number]' in the Pull Request description). By adding "closes #issue" or something similar in a comment on a pull request, merging the pull request will close the issue automatically.
  • once completed, approve Pull Requests (for the contributors to merge them) and/or close issues immediately (if not linked to specific Pull Request) with a comment describing how it was addressed.
  • when reviewing a pull request or commenting on issues, be specific, describe your ideas clearly, comment to request changes or make a pull request to the file that should be merged (please do not use the "request changes" option when reviewing Pull Requests).
  • use your interactions on GitHub or other community spaces to provide support, mentorship and acknowledgement to our community of contributors.

Acknowledgments

We have used The Turing Way's ways of working document as a template for this document.