Contributing

From Portico

Jump to: navigation, search

Portico is open source software, and as such, we encourage community participation in the support and development of the project. Contribution can come in many forms, not just the submission of patches. Anyone can help out in the following ways:

  • Report Bugs: tell us when something doesn't work!! (this is one of the most important ways to contribute!) See Reporting Bugs
  • User Support: answer questions on the forums, tell people about Portico and so forth
  • Documentation: be it fixing a minor typo, or writing a full guide
  • Authoring of Plugins: Portico has a special plugin framework for writing extensions. Help add new functionality by releasing your own plugins!
  • Contribution of code/bug fixes: the typical open source way. We gladly accept patches from anyone who has the time to make them, and will incorporate them into the main codebase according to the Contribution and Management Policies.

To properly acknowledge the efforts of contributors, a special page outlining who they are and what they contributed will be created. Portico is a meritocracy, and if someone is continually providing high-quality patches, they may be invited to join the developer group and issued commit access. See Contribution and Management Policies for more information.

[edit] Source Contributions

All code contributions should be sent in as patches (where possible). See Patches for details information on creating and applying patches.

The basic process for submitting a code contribution is as follows:

  1. Discuss the proposal with the core developers
  2. Register an issue for it (see Reporting Bugs)
  3. Attach any patches to the issue
  4. When the contribution is accepted, the issue will be closed

It is important that all patches relate to an issue registered in the Portico issue database. This will give it a unique number and identity which can be used to track it. Anyone can register issues on the tracker, and the procedure is the same as for registering bugs. See Reporting Bugs for more details on how to do that.

It is also important that you discuss any plans for contribution with the core developers. They can help guide you with things like project conventions. It also helps to ensure that your patch meets all the structural requirements they may ask of it for inclusion, thus helping to ensure that your hard work makes it into the distribution.

Most discussion will happen on the forums or developer mailing list. Here you will be able to engage with the core developers and get some help to make sure your patch is accepted. There are very few reasons why a contribution would be rejected. Sometimes, a proposed addition might be better packaged as a separate plug-in (for example: a DIS-bridge communications binding) rather than going into the main distribution. Perhaps the patch includes internal changes that are deemed too significant or could be achieved via a slightly different approach. Either way, the goal of the process put in place is to allow open and frank discussion. Anyone who wants to submit a patch should, and they are welcomed and strongly encouraged to do so.