Add contributing guide #81
Conversation
| It is the responsibility of the pull request author to convince the reviewers that the change | ||
| is reasonable, complete and an improvement to windIO. | ||
|
|
||
| Some guidelines: |
There was a problem hiding this comment.
I thought if this could be aided by using a Changelog ?
I think it enhances the contributors addition that they have to explain in plain words what they did and that it has to be concise since it is in bullet-point format. It is also a good way to see what changed between versions.
There was a problem hiding this comment.
I'm all for a change log, but maybe in a few weeks as there will lots of changes coming in the next few weeks
| - Data or reference models should include links to their published sources. | ||
| - The pull request's source branch can live either on the main repository or on a fork. | ||
|
|
||
| .. Consider this checklist as a starting point to ensuring a pull request is complete: |
There was a problem hiding this comment.
We could also consider to use pull-request templates to guide the process: https://github.com/github/docs/blob/main/content/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository.md
There was a problem hiding this comment.
Great idea @kenloen. I adapted the one I put together for FLORIS in f8f05a7. If you want to see how it looks in the PR creation form, hit the "Create pull request" button at rafmudaf/floris@main...develop. That's on my fork of FLORIS, no worries if you accidentally submit it.
|
I've updated this pull request following suggestions from a meeting this morning. Please feel free to review again. Otherwise, if I don't hear anything I'll signal to @ptrbortolotti that it's ready to merge by tomorrow afternoon. |
This was used to create a live preview during development
|
@ptrbortolotti From my side, this is ready. |
This pull request adds a contributing guide to the existing online documentation. The intent is to clearly and explicitly state the processes, roles, and expectations around windIO contributions so that we can understand how to move through the process effectively. Please consider this a proposal, and I'm happy to hear any feedback.
You can view a live version at https://rafmudaf.github.io/windIO/source/developer_guide.html.
The sections are as follows:
Note I'll delete the
gh-pagesworkflow before merging. The preview is built on GitHub Pages rather than readthedocs for simplicity.