-
-
Notifications
You must be signed in to change notification settings - Fork 62
Conversation
This CoC is adapted from the WeAllJS Code of Conduct. Since that one is primarily based around Slack communities, some changes needed to be made to make it usable on GitHub.
d3fb602
to
0fe1236
Compare
0fe1236
to
bb0408b
Compare
bb0408b
to
8037689
Compare
8037689
to
fee7472
Compare
fee7472
to
c7ba4ff
Compare
CODE_OF_CONDUCT.md
Outdated
|
||
## Our Pledge | ||
|
||
In the interest of fostering an open and welcoming environment, we as contributors and maintainers of this projet pledge to making participation in our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, technical preferences, nationality, personal appearance, race, religion, or sexual identity and orientation. |
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.
"projet" should be "project"
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.
it's fine. It's French.
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.
No.
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.
🤔
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.
CONTRIBUTING.md
Outdated
|
||
Please make sure to read the relevant section before making your contribution! It will make it a lot easier for us maintainers to make the most of it and smooth out the experience fo all involved. 💚 | ||
|
||
Don't worry if the document seems long: You probably only need to read one little section for whatever you'd like to do. 😉 |
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.
I don't think this sentence is needed at all.
CONTRIBUTING.md
Outdated
* [Set up the project](#project-setup). | ||
* Edit or add any relevant documentation. | ||
* Make sure your changes are formatted correctly and consistently with the rest of the documentation. | ||
* Re-read what you wrote, and possibly run a spellchecker on it to make sure you didn't miss anything. |
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.
remove "possibly"
CONTRIBUTING.md
Outdated
* Make any necessary changes to the source code. | ||
* Include any [additional documentation](#contribute-documentation) the changes might need. | ||
* Write tests that verify that your contribution works as expected. | ||
* In your commit message(s), begin the first line with `COMPONENT:`, where `COMPONENT` is the relevant component, feature, or section of the code. There's no hard line for this, but look at the commit history for ideas. |
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.
Would a bug fix also need to be "COMPONENT"?
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.
I feel like I should clarify this cause it got confusing -- and as far as bugfixes though, I think I'm more interested in the component the commit affects, rather than whether something is a bugfix or a feature tweak or whatever? So extract: fix tarball lockup issue
rather than fix: tarball extract issue
.
An alternative is to just go ahead and use angular-style commit messages, which have a standardized format and some automated tooling built around them. See: https://github.com/conventional-changelog/conventional-changelog-angular/blob/master/convention.md
What do you think? I'm not interested in using semantic-release, but this format would actually let us autogenerate changelogs, which would be handy.
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.
I think I tend to use angular-style. I like that style but having yours clarified, I also understand the component based approach :)
This is fantastic. 🎶 I have some questions, a couple of suggestions (in my review) 🎶 |
@Charlotteis thanks for taking the time to review! It sounds like the format is good, so I'll sit down and bang out the rest of the document so we can do one final review before merging. And as far as using it goes: please, feel free to use any of the docs here for anything you want. It's all public domain and you know how I am about documentation reuse <3 |
c53ac05
to
4e7de93
Compare
4e7de93
to
864261b
Compare
CONTRIBUTING.md
Outdated
|
||
[Needs Access](#join-the-project-team): none | ||
|
||
Helping out other users with their questions is a really awesome way of contributing to any community. It's not uncommon for most of the issues on an open source projects being simply support-related questions by users trying to understand something they ran into, or find their way around a known bug. |
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.
remove "simply"
CONTRIBUTING.md
Outdated
|
||
One of the most important tasks in handling issues is labeling them usefully and accurately. All other tasks involving issues ultimately rely on the issue being classified in such a way that relevant parties looking to do their own tasks can find them quickly and easily. | ||
|
||
In order to label issues, simply [open up the list of unlabeled issues](https://github.com/zkat/pacote/issues?q=is%3Aopen+is%3Aissue+no%3Alabel) and, **from newest to oldest**, read through each one and apply issue labels according to the table below. If you're unsure about what label to apply, simply skip the issue and try the next one: don't feel obligated to label each and every issue yourself! |
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.
remove "simply" x 2
f59ac0d
to
92faf5e
Compare
@Charlotteis could you review again? This is done. |
CONTRIBUTING.md
Outdated
|
||
[Needs Access](#join-the-project-team): Issue Handler | ||
|
||
While anyone can comment on a PR, add feedback, etc, PRs are only approved for merger by team members with Issue Handler or higher permissions. |
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.
"approved for merge" sounds better than "approved or merger" to me.
One nitpick. Also, a question: What 'role' do I have? Committer, Labeller, Owner, Admin? |
92faf5e
to
44d0e79
Compare
This is great! Issues for the following sections:
Should be created :) |
I also created two issues to fill the remaining two sections. This is awesome. Thanks for writing this and I look forward to using them in my own projects. |
This PR adds a Code of Conduct as well as a contributing guide. Hopefully, this will give folks hoping to contribute a clear idea of what to expect, as well as information on what they can do and how they can do it.
Before I complete this PR, it would be really great to get feedback on the general structure of CONTRIBUTING.md in case I'm just making some grave mistake. Cause it's a lot of writing to be doing :\