Table of Contents
Participating in the community
The community exists mainly through the
Issue Tracker, the Discussions and the
There are many ways to join the project, either by writing code, or by testing and/or helping to manage the upcoming features / bugfixes. Go to http://nearforums.codeplex.com/ and
- Join the discussions mailing lists by clicking on the E-Mail Notifier box on the right sidebar of the main pages of Discussions and Issue Tracker.
All development questions should go to Discussions, though you might want to check the previous posts.
- Subscribe to the rss of nearforums project to see what is happening (commits/wiki updates/etc): http://nearforums.codeplex.com/project/feeds/rss.
- See upcoming features and bug fixes on the
Issue Tracker. Vote and comment on the ones you find interesting in order to prioritize.
- Submit a patch for a feature or bug. To do so, you can
create a fork in the source code tab of the project (see
how to create forks / pull requests on Codeplex). Each fork is a copy of the full source code repository that you own entirely. You should read the
development instructions for further info.
Despite the online nature of the nearforums project and the human contact abstraction that results from that fact, it is important to realize that there are real people at the end of all contributions.
Treat all other community members as you would expect to be treated. Review the contribution, not the contributor; don't annoy others, and don't become easily annoyed yourself.
Code to read
Before you can contribute code, you'll need to familiarize yourself with the existing code base. Take a look at how controllers, views, client services and entities are written.
Get a copy of
nearforums repository (anonymously, if you don't yet have an account with commit access) — so you can look at the code.
The best way to have a healthy development community is to look at each others' code. Again, review the contribution, not the contributor.
Code reviewing helps to maintain software quality and helps developers learn from each other.
Reviews should be public using the mailing list.
Formal roles with corresponding responsibilities are established. See Governance for further info.
This document is based on Apache Subversion Community Guide, licensed under
Apache License, Version 2.0.
Copyright © 2011 Outercurve Foundation, Licensed under