Skip to content

Latest commit

 

History

History
204 lines (134 loc) · 10.9 KB

CONTRIBUTING.md

File metadata and controls

204 lines (134 loc) · 10.9 KB
Raw

Contributing to FOSH-following-demand

Welcome to the FOSH-following-demand repository! We're excited you're here and want to contribute.

These guidelines are designed to make it as easy as possible to get involved. If you have any questions that aren't discussed below, please let us know by opening an issue!

Before you start you'll need to set up a free GitHub account and sign in. Here are some instructions.

Already know what you're looking for in this guide? Jump to the following sections:

Joining the conversation

FOSH-following-demand is a young project maintained by a growing group of enthusiastic developers— and we're excited to have you join! Most of our discussions will take place on open issues. We also maintain a gitter chat room for more informal conversations and general project updates.

There is significant cross-talk between these two spaces, and we look forward to hearing from you in either venue! As a reminder, we expect all contributions to FOSH-following-demand to adhere to our code of conduct.

Contributing through GitHub

git is a really useful tool for version control. GitHub sits on top of git and supports collaborative and distributed working.

You'll use Markdown to chat in issues and pull requests on GitHub. You can think of Markdown as a few little symbols around your text that will allow GitHub to render the text with a little bit of formatting. For example you could write words as bold (**bold**), or in italics (*italics*), or as a link ([link](https://https://youtu.be/dQw4w9WgXcQ)) to another webpage.

GitHub has a helpful page on getting started with writing and formatting Markdown on GitHub.

Understanding issues, milestones and project boards

Every project on GitHub uses issues, milestones, and project boards slightly differently.

The following outlines how the FOSH-following-demand developers think about these different tools.

  • Issues are individual pieces of work that need to be completed to move the project forwards. A general guideline: if you find yourself tempted to write a great big issue that is difficult to describe as one unit of work, please consider splitting it into two or more issues.

    Issues are assigned labels which explain how they relate to the overall project's goals and immediate next steps.

  • Milestones are the link between the issues and the high level strategy for the FOSH-following-demand project. Contributors new and old are encouraged to take a look at the milestones to see how we are progressing towards FOSH-following-demand's shared vision.

    Issues are assigned to these milestones by the maintainers. If you feel that an issue should be assigned to a specific milestone but the maintainers have not done so, just ask! We might have just missed it, or we might not (yet) see how it aligns with the overall project structure. These conversations are important to have, and we are excited to hear your perspective!

  • The project board is an automated Kanban board to keep track of what is currently underway (in progress), what has been completed (done), and what remains to be done for a specific release. The FOSH-following-demand maintainers use this board to keep an eye on how tasks are progressing week by week.

Issue labels

The current list of labels are here and include:

  • Help Wanted These issues contain a task that a member of the team has determined we need additional help with.

    If you feel that you can contribute to one of these issues, we especially encourage you to do so!

  • Bugs These issues point to problems in the project.

    If you find new a bug, please give as much detail as possible in your issue, including steps to recreate the error. If you experience the same bug as one already listed, please add any additional information that you have as a comment.

  • Enhancement These issues are asking for enhancements to be added to the project.

    Please try to make sure that your enhancement is distinct from any others that have already been requested or implemented. If you find one that's similar but there are subtle differences please reference the other request in your issue.

  • Good First Issue These issues are good places for new comers to test the waters and start contributing.

Making a change

We appreciate all contributions to FOSH-following-demand, but those accepted fastest will follow a workflow similar to the following:

1. Comment on an existing issue or open a new issue referencing your addition.

This allows other members of the FOSH-following-demand development team to confirm that you aren't overlapping with work that's currently underway and that everyone is on the same page with the goal of the work you're going to carry out.

This blog is a nice explanation of why putting this work in up front is so useful to everyone involved.

2. Fork the FOSH-following-demand repository to your profile.

This is now your own unique copy of FOSH-following-demand. Changes here won't effect anyone else's work, so it's a safe space to explore edits to the code!

Make sure to keep your fork up to date with the master repository.

3. Make the changes you've discussed.

Try to keep the changes focused. We've found that working on a new branch makes it easier to keep your changes targeted.

When you're creating your pull request, please make sure to review the FOSH-following-demand style conventions.

4. Submit a pull request.

A member of the development team will review your changes to confirm that they can be merged into the main code base. When opening the pull request, we ask that you follow some specific conventions. We outline these below.

Pull Requests

To improve understanding pull requests "at a glance", we encourage the use of several standardized tags. When opening a pull request, please use at least one of the following prefixes:

  • [BRK] for changes which break existing builds or tests
  • [DOC] for new or updated documentation
  • [ENH] for enhancements
  • [FIX] for bug fixes
  • [REF] for refactoring existing code
  • [STY] for stylistic changes
  • [TST] for new or updated tests, and
  • [WIP] for changes which are not yet ready to be merged

Pull requests should be submitted early and often! If your pull request is not yet ready to be merged, please also include the [WIP] prefix. This tells the development team that your pull request is a "work-in-progress", and that you plan to continue working on it.

You can also combine the tags above, for example if you are updating both a test and the documentation: [TST, DOC]. If you're still working on the pull request that prefix would be [WIP, TST, DOC].

Style Guide

We encourage extensive documentation.

The website is developed using Jekyll, in the same website you'll find a tutorial section which shows people how to get started, if you never worked with this system.

Recognizing contributors

We welcome and recognize all contributions from documentation to testing to code development. You can see a list of current contributors in the contributors tab.

Thank you!

You're awesome. 👋😃


— Based on contributing guidelines from the STEMMRoleModels project.