Table of Contents

Participating in the community

The community exists mainly through the Issue Tracker, the Discussions and the repository

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.

Communication

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.

Code reviewing

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.

Project Governance

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 MIT.

Last edited May 16, 2013 at 4:01 PM by jorgebg, version 19

Comments

No comments yet.