Skip to content

Conversation

@kalaspuffar
Copy link
Member

Hi @bertfrees, @PaulRambags, and @joeha480

What do you think about these contributing agreement?
Could this be added to all repositories?

Best regards
Daniel

Copy link
Contributor

@joeha480 joeha480 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link

@PaulRambags PaulRambags left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please merge this Contributing agreement with the one that Joel points to.

CONTRIBUTING.md Outdated

We are trying to keep an consistant coding convention in order to help readablility and make it easy to submit code.

Things to refrain from:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The coding style should express the desired behaviour. Instead of listing things you must not do, you should be clear and mention what you should do.
Please rewrite so that this line starts with "Try to stick to:"

@kalaspuffar
Copy link
Member Author

Hi @joeha480, @bertfrees and @PaulRambags.

I've updated this document to incorporate the contribution guide on the wiki. This document might not be required or could just have a link to the wiki, but following the Github guide it's a commonplace where contributors can find information, so having this document could improve reach.

I'm not saying this is the final document, but it's at least more in line with the current project and has the right links.

I am looking forward to your feedback.

Best regards
Daniel

@bertfrees
Copy link
Contributor

bertfrees commented Aug 1, 2019

Some suggestions:

  • Something like: If fixing the issue requires a change in the OBFL specification (maybe refer to https://github.com/brailleapps/wiki/wiki/Software-Architecture), an issue should also be made in the https://github.com/braillespecs/obfl repository, and an agreement should be reached and documentation and schema updated.
  • If you don't know how to fix the issue, providing some tests can already be very helpful. (applies to all issues I guess)
  • Team might run regression tests and you may be asked to fix possible problems.
  • If applicable, use "@" to mention people. (applies to all issues)
  • Javadoc isn't mentioned anywhere, also not on the Principles wiki page. But it's quite important that PRs contain Javadocs and/or other comments. Not necessarily when the PR is created, but the team will ask for it anyway, possibly as the last step when all requested changes to the code itself are done.

And yes I agree that having the file in the CONTRIBUTING file in the source code is useful. It would also have been OK to just put a link in it to the wiki (or the other way around). (By the way I also find it useful to have a NEWS/ file in the source code, instead of having that information only on Github. But that's a different topic.)

Copy link
Contributor

@bertfrees bertfrees left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants