-
Notifications
You must be signed in to change notification settings - Fork 683
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
Add a document with contribution guidelines #275
Conversation
r? @carllerche |
b559dd5
to
3fa7c62
Compare
The part of this I'm really excited about is the issue labels. There are probably more to add, but here's a start! |
@abbradar as a new contributor, would a document like this be helpful? |
The [homu] link seems wrong. |
Several more things which might be useful:
(BTW I'll continue working on my patches later, as I'm a bit short of time now) |
Fixed, and added a link to the queue as well. |
@abbradar thanks for the comments!
I'm going to leave this out for now. I'm planning to make real progress on https://github.com/nrc/rustfmt/issues/434 and hopefully soon we'll be able to just say "run
I think these belong in the conventions doc. There's definitely more that needs to go in there though. Thanks for the suggestions!
Hm, I thought this would be implied by us having travis-ci set up. How do you think I could make it clearer? |
Also cc: @posborne :-) |
Travis forces the "tests should pass" policy but from my experience reminding that contributors should run final tests on their own machines somewhere can nevertheless reduce the volume of "Travis fails on this patch; can you please look?" messages from maintainers. An example would be yours truly -- I didn't have much Rust experience so I actually found out about |
It's probably a decent idea to include a small section on testing. Something that describes how to run the tests and instructs contributors to include tests with their PR when appropriate, etc. |
Agreed. I am working on some additional test infrastructure for several of the more exotic targets (ARM, bsd, ...) and will do my best to come up with a solution that would allow for tests to be run locally (using docker, qemu, etc.) in a way that matches what Travis will be running. This should make it easier to both contribute to those platforms and avoid regressions. |
No, your changes were great! We just need better documentation around contributing. :-) |
That would be so great. |
Looks good to me! |
Looks good here too! |
The moment the merge conflict and the build failure (how can either happen, with a completely new file that is not code ...) are resolved I propose to merge this. |
This gives us a place to point new contributors, as well as to document our project practices.
6a6508b
to
901f3e5
Compare
📌 Commit 901f3e5 has been approved by |
Add a document with contribution guidelines This gives us a place to point new contributors, as well as to document our project practices.
☀️ Test successful - status |
This gives us a place to point new contributors, as well as to document
our project practices.