One of the most important aspects reflecting the quality of an open source project is the availability of high quality documentation. There are two broad classes of documentation:
Like good documentation, code quality is an essential ingredient for success. The Core team is dedicated to making sure high priority bugs are fixed, and we need your help to get an accurate account of oustanding issues. We also welcome feature requests filed in the same tracking system.
If you run across an issue with the software release or documentation, or this site, do the following:
As you start to learn about CCNx, you will find that we've only scratched the surface on what can be done. In order to leverage the expertise of the community, we offer this site as a great place to start your CCNx project, to organize your project team, socialize the project, and get support from the community. Creating a project is simple. From the navigation menu, select Create Content->Project Group. Once you've created a project, you can add members to the project, configure the project settings, and start adding new Project Pages. Feel free to upload your important project documents, and share these with the project members as well. Of course, if you need to keep aspects of your project private, you can do this. For hosting any source code, we strongly recommend GitHub, BitBucket, or Google Code (if you must use Subversion).
Another way you can get involved is to help others. A successful Open Source community needs a strong group of domain experts who can help fill in the resource gaps by answering questions and sharing wisdom about the project. While the Core Team will do this as well, it can be a huge way to help provide rapid response to user and developer related questions. As this is a community, we'd ask you review the CCNx Community Principles. Ultimately, mailing lists provide the first level of support for an Open Source project after the docs or the code has failed. Sure, users don't always have a handle key concepts, or haven't read the docs, but we'd like encourage questions with thoughtful answers. No flames or throwing the manual at users. Also, works for me doesn't work as an answer. Usually there is a deeper issue, usually with the environment, but if we can identify new bugs, we'd like to drill down into every problem we find so we can improve the project.
One way to support the CCNx project is to help spread the word. Have something interesting to say about CCNx? Having problems with the latest build? Want to tell people about something interesting you are doing with CCNx? Tweet it. When doing so, use the #ccnx hash tag with your tweets. This helps contextual search and increases the visibility of your posts.
Come across an interesting tweet about Project CCNx? Re-tweet it.
We encourage contributions to the source code (including documentation in the code tree). In order to make contributions you must first sign and return the Contributor Agreement to assure that contributed code may be redistributed consistent with the open source licenses used in Project CCNx. In addition, we request that all contributors:
Project CCNx uses git for managing the source code. You can submit a patch created with git format-patch for consideration by the Core Development team. (Instructions coming)