Skip to content

Latest commit

 

History

History
39 lines (31 loc) · 4.08 KB

contributing.md

File metadata and controls

39 lines (31 loc) · 4.08 KB

My Portfolio contributing guidelines

First, I would like to thank you for viewing this policy. If you intend to actively work on my project, that will save both of us a lot of time and nerves! 👍

📚 Table of contents

  1. "Why should I read this?"
  2. "How can I benefit from working here?"
  3. "What kind of guidelines are there? "
  4. "Where is the best place to talk to the development team?"

⏰ "Why should I read this?"

You have probably already started working on a project many times and only realized hours later that a simple look at the documentation would have saved you many hours and the associated nerves. It is exactly the same with the Contribution Guidelines here. Here I explain to you what I thought when setting up the project and what the specifications for creating content for this project have to look like. Of course, this is just a documentation of the "most ideal solution" for me. But that has not made these guidelines binding for a long time, so don't worry about that. You will also find some explanations here that should explain some of the unusual features.

🏆 "How can I benefit from working here?"

As with other developments, you can gain experience here, take a look at someone else's code and take a look at the frameworks and systems I have chosen. You can find a list of these systems in the ReadMe.

☑️ "What kind of guidelines are there? "

1. Branches

Branch name Prefix Usage Example
Production release Branch main (Unique Stable) Production Branch. There is only one of this branch: production.
Release Branch release/ Completed releases that are named by the time. (YEAR.MONTH.VERSION_NUMBER) release/2021.7.1
Feature Branch feature/ The feature branch only comes with major updates that are being worked on over the long term. feature/ux-update
Bug Branch bug/ The name should speak for itself: currently fixed bugs. bug/footer-position-fix
Developer Branch dev/ The dev branch is intended for small changes that do not belong to any other category. dev/nicokempe

2. Issues

I created extra templates for creating issues. These were generated by GitHub and adapted by me. They should help everyone involved to resolve the issue quickly. When creating issues you will be asked directly whether you want to use them. And your answer should definitely be yes.

3. Pull requests

If you want to create a pull request then check the checkboxes in the footer and really work with Markdown to make it easier to read. In general, you should just enter as much information about your changes as is necessary.

4. Commits

There are no templates for the commits. The general rule is: the title expediently and the description as detailed as possible. I will then express further specifications and more precise requests when the templates are ready.

💬 "Where is the best place to talk to the development team?"

That depends entirely on the intended use. If you have a question about a piece of content on GitHub that has a comment section - use this one! If this does not exist, however, then do not look for contact options on the profiles of the developer but start a discussion in the section provided on GitHub.