These are excellent questions! They way my team started open source is essentially by jumping into the cold water, so to speak.
There is obviously a lot of prior around that at Microsoft, specifically WiX, ASP.NET, TypeScript, and Roslyn but each community and project is slightly different. We've talked a lot with people on these these projects -- and still do -- to learn from each other. However, I think it's also fair to say that we started by treading a way and will improve over time until it becomes a fully paved highway.
What would you want a first-time contributor to know before forking a project or considering a pull request?
For any project you should first check out the contribution guidelines. The usual convention on GitHub is putting a a file called
CONTRIBUTING.md or similar name in the root of the repository. For the .NET Core Framework, the file can be found here.
Where would you send them to learn before they write a line of code?
That's a good question. The way I see this is similar to how any social interaction works. When you're invited to a party in someones house you've never been to, you usually start by chatting with a few folks and observe the kind of conversation that are happening there before you jump in and share a story from your life.
I think open source works similar. You should take a look at some of the pull requests and see what kind of feedback people get. This gives you an idea of what folks care about. You should also look at the issue tracker and look for open bugs to get a handle on the direction of the project. If the project has a roadmap, you should read it (we'll share one for .NET Core soon).
Most projects encourage folks to file an issue before starting to invest a lot of time into coding. This ensures that both parties can get on the same page to see whether that's the right direction for the project. It's also a good starting point for discussing design options.
Some projects also mark their issues as up-for-grabs to indicate issues they need help with from the community. We've started to do the same.
What are appropriate expectations for contributions being accepted?
I think from our point of view it's really about these two parts:
Roadmap. All projects focus their energy on certain areas. In order to keep the focus and the momentum it’s important that most of the work is aligned with the product’s roadmap.
Quality. We’ve a responsibility for shipping high quality code. Therefore, external folks have to meet the same quality bar that Microsoft employees have to meet. This includes having the right design, architecture, sufficient test coverage and following the coding style.
We believe by doing the development in the open we provide enough context for external developers to be successful. For example, you’ll be able to observe our code reviews and read documentation about how the internals are designed.
And when in doubt: ask.