Serial podcast creator and .NET Core maniac.
Can often be found talking about everything and nothing on one of the many podcasts that he produces (only one of them is about .NET Core, honest)
Location
Leeds, UK
Education
Computer Science with Games Development - BSc
Work
.NET Development Contractor; Podcast host, producer and editor
A few things that I've learned over the last year or so:
Contributors
Have some kind of markdown file with instructions for contributors. Should folks who want to contribute create an issue before sending a PR? Should contributors work in their forked version of Master?
Some information on the contributors markdown file can be found here
Code of Conduct
Unfortunately, this has become a requirement of late. Need I mention Linus' track records of being offensive towards contributors to the Linux kernel?
(regardless of how you feel about his reactions, a code of conduct is always a good idea).
Do you expect certain behaviours from your contributors? By having a code of conduct, you are explicitly telling contributors how you want them to behave and conduct themselves whilst contributing to your repo.
Issues
When logging issues (even on my own repos), I try to be as descriptive about the issue as possible. Here's an example of one of my issues for OwaspHeaders.Core:
The OwaspHeaders.Core middleware does not yet include support for Feature-Policy which is a header related to enabling or disabling certain JavaScript API features.
Quote from Scott Helme's blog:
TheFeature Policy is being created to allow site owners to enable and disable certain web platform features on their own pages and those they embed. Being able to restrict the features your site can use is really nice but being able to restrict features that sites you embed can use is an even better protection to have.
It's not the best example of an issue, but it's one of my most detailed ones.
The idea is that you want to give potential contributors the most information that you can, in order to get them up to speed with the issue as quickly as possible.
Where possible I try to include a pseudo-code version or 10k ft view of a possible solution, and include links to lines in the code base where the solution could be implemented, too.
Serial podcast creator and .NET Core maniac.
Can often be found talking about everything and nothing on one of the many podcasts that he produces (only one of them is about .NET Core, honest)
Location
Leeds, UK
Education
Computer Science with Games Development - BSc
Work
.NET Development Contractor; Podcast host, producer and editor
A few things that I've learned over the last year or so:
Contributors
Have some kind of markdown file with instructions for contributors. Should folks who want to contribute create an issue before sending a PR? Should contributors work in their forked version of Master?
Some information on the contributors markdown file can be found here
Code of Conduct
Unfortunately, this has become a requirement of late. Need I mention Linus' track records of being offensive towards contributors to the Linux kernel?
(regardless of how you feel about his reactions, a code of conduct is always a good idea).
Do you expect certain behaviours from your contributors? By having a code of conduct, you are explicitly telling contributors how you want them to behave and conduct themselves whilst contributing to your repo.
Issues
When logging issues (even on my own repos), I try to be as descriptive about the issue as possible. Here's an example of one of my issues for OwaspHeaders.Core:
Description
The OwaspHeaders.Core middleware does not yet include support for Feature-Policy which is a header related to enabling or disabling certain JavaScript API features.
Quote from Scott Helme's blog:
Source: A new security header: Feature Policy
Links to Header Information
It's not the best example of an issue, but it's one of my most detailed ones.
The idea is that you want to give potential contributors the most information that you can, in order to get them up to speed with the issue as quickly as possible.
Where possible I try to include a pseudo-code version or 10k ft view of a possible solution, and include links to lines in the code base where the solution could be implemented, too.
Thank you so much! I added the COC and Contributor guide to the issues -- both are so important, and should definitely be addressed ASAP.
Great advice on issues too -- thank you!
Not a problem.
Like all of us, I'm still trying to figure out how to be a great open source contributor and maintainer.
I'd suggest checking out Contributor Covenant
contributor-covenant.org/
Yes! Definitely going to add that, and maybe add some additional language with positive actions in addition to negative.