-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Further improves CONTRIBUTING #334
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall, would also be helpful if there was a checklist (maybe as a template). Based on what you wrote, would be something like
Conditions for PR to be approved:
- PR contains only Python code
- PR does not add dependency
- PR does not contain Python Classes
- PR follows code style
- PR passes tests
- PR does not break license
If any of these criteria are not met, add a detailed justification below:
...
Thanks Rodrigo. I will add those in the PR template. Okay Alexandre, will add that info too. |
Codecov Report
@@ Coverage Diff @@
## main #334 +/- ##
==========================================
+ Coverage 57.73% 57.74% +0.01%
==========================================
Files 61 61
Lines 3712 3711 -1
==========================================
Hits 2143 2143
+ Misses 1569 1568 -1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed the grammar of some bits, see if you agree.
-test.cfg
examples
This is real-world Doublethink
🐑
Great 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I just thought of something else; I am fine with following arbitrary rules (as long as they are clear, and I think this PR makes it much more clear), but since we want to have a community developing for haddock3, would be nice if the rules had some sort of motivation - if you think its relevant, of course.
For example:
- Only python code - why?
- Avoid use of classes - many of us when we learn python, classes are there on lesson 2. So why not use them? How do they affect HADDOCK in a bad way?
- Does not add dependencies - if we are working on an open source and community driven project, why not use things that the community have developed? doesn't this go against
Don't Repeat Yourself
paradigm? - Why attach testing to
tox
? (This makes tox a dependency) - Shouldn't different modules be allowed different styles? They should be indeed modular and separate from the main code.
- What is considered "well documented", docstrings with parameters and return or just a lot of # on top of each line?
Just a few points that I can think off, of course if you don't agree with answering this or don't think this is needed for the community, also fine.
Only python code - why?
I guess only for the module machinery, but the module might call software written in different languages - we already have Fortran with CNS.
And some other components might be in different languages. E.g. if we build a gromacs module
Performance is important here.
Does not add dependencies - if we are working on an open source and community driven project, why not use things that the community have developed? doesn't this go against Don't Repeat Yourself paradigm?
Any new module will add dependencies if it integrates some new software… Unavoidable.
|
Based on what we discussed elsewhere, I've added a new step 6 that explains the motivations behind the contribution rules so that it is also clear for someone outside the group, think this one can be merged! Thanks for making this clear @joaomcteixeira ;) |
Made some improvements for clarity |
Completes the
CONTRIBUTING
guidelines. This should be enough. TheCONTRIBUTING
file is not an explanation of how to use github or how to dev code, but how to interact with the project. Do you find something missing? You can read the rendered markdown version of the file here.