We are very grateful to everyone who is showing interest in the project and to anyone who helps improve it. No contribution is too small and all contributions are valued.
The project has a Code of Conduct that all contributors are expected to follow. This code describes the minimum behavior expectations for all contributors.
There are several ways you can help Vita's development:
-
Blog about Vita.
-
Report bugs and request features in the issue tracker. Before reporting a bug or requesting a new feature please consider these general points:
- check that someone hasn't already filed the bug or feature request by searching or running custom queries in the issue tracker;
- we will try to respond in a timely manner, but understand that Vita is provided as-is, i.e. with no promise of support. Most people give support in their spare time, so it may take some time before you get an answer;
- don't reopen issues that have been marked wontfix by a core developer. This mark means that the decision has been made that we can't or won't fix this particular issue;
- well-written bug reports are incredibly helpful. Please do write complete, reproducible, specific bug reports. Include as much information as you possibly can, complete with code snippets, test cases... This means including a clear, concise description of the problem and a clear set of instructions for replicating the problem. A minimal example that illustrates the bug in a nice small test case is the best possible bug report;
- report security issues marking them with the security label. Different people support different ways of disclosure of security issues. At the moment full disclosure seems a valid choice for this project. We take security seriously and try to investigate all reported vulnerabilities as soon as possible. Anyway addressing a valid reported vulnerability can take time (this will vary based on the severity of the vulnerability and the affected systems).
-
Improve the documentation. Did you find a typo? Do you think that something should be clarified? Go ahead and suggest a documentation patch! Your help in this area is much much appreciated since English is not our mother tongue
-
Triage tickets that have been created by other users. If a ticket is unreviewed and reports a bug, try and reproduce it. If you can reproduce it and it seems valid, make a note that you confirmed the bug and accept the ticket. Make sure the ticket is filed under the correct component area. Consider writing a patch that adds a test for the bug’s behavior, even if you don't fix the bug itself.
-
Submit patches for new and/or fixed behavior (requires to sign a CLA).
- if you're looking for an easy way to start contributing to Vita, have a look at the easy pickings tickets. If you're going to engage in a big task, make sure that your idea has support first. This means getting someone else to confirm that a bug is real before you fix the issue and ensuring that the core team supports a proposed feature before you go implementing it;
- browse the development cycle to find out how to give your code patches the best chances to be included in Vita core.
-
Write unit tests.
-
Artwork. Do you have artistic talent? Then you could work on the art assets of the project like icons or logos. Not just the software itself but also its website and promotional material can certainly benefit from your skills.
...and many more ways! Really, ANYONE can do something to help make Vita better.
Approved contributions will be recorded on the commit logs and author's name will appear in the contributors/ directory.
The general strategic line is drawn by the project owner.
It's his job to resolve disputes within the community and to ensure that the project is able to progress in a coordinated way.
The lead’s job is then to ensure that the committers (see below) make the right decisions on behalf of the project. Generally speaking, as long as the committers are aligned with the project’s strategy, the project lead will allow them to proceed as they desire.
In turn, it is the community’s job to guide the decisions of the project owner through active engagement and contribution.
Committers are contributors who have made several valuable contributions to the project and are now relied upon to both write code directly to the repository and screen the contributions of others. In many cases they are programmers but it is also possible that they contribute in a different role. Typically, a committer will focus on a specific aspect of the project, and will bring a level of expertise and understanding that earns them the respect of the community and the project lead. The role of committer is not an official one, it is simply a position that influential members of the community will find themselves in as the project lead looks to them for guidance and support.
Contributors are community members who either have no desire to become committers, or have not yet been given the opportunity.
Anyone can become a contributor. There is no expectation of commitment to the project, no specific skill requirements and no selection process. To become a contributor, a community member simply has to perform one or more actions that are beneficial to the project.