We are excited that you are interested in contributing to Swahilinux. Swahilinux is beginner friendly and everyone is welcome to contribute.
All members of our community are expected to follow our Code of Conduct. Please make sure you are welcoming and friendly in all our spaces.
- On Telegram - Swahilinux
Swahilinux projects are open-source projects and we love to receive contributions from our community, i.e. you. There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submiting bug reports and feature requests or writing code which can be incorporated to one of the Swahilinux projects.
There are several ongoing projects under Swahilinux. If you are interested in helping out with the development(basically, code) of a project, then first you need to get a local copy of the project depending on the installation guide of that project. Installation guides are usually found on the README file.
Documentation for any Swahilinux project is hosted by Wiki at Wiki.
There are guidelines around writing and formatting documentation. For full details, including how to build it, see Buiding and Contributing to Documentation.
The goal is to maintain a diverse community that's pleasant for everyone. That's why we would greatly appreciate it if everyone contributing to and interacting with the community also followed this guidelines.
- Be respectful.
- Be considerate.
- Be collaborative.
- When you are unsure, ask for help.
- Be welcoming to newcomers and encourage diverse new contributors from all backgrounds. See the Swahilinux Community Code of Conduct
- Each pull request should implement ONE feature or bugfix. If you want to add or fix more than one thing, submit more than one pull request.
- Do not commit changes to files that are irrelevant to your feature or bugfix (e.g.:
.gitignore). - Ensure that code that goes into core meets all requirements in this checklist: Checklist
New contributor and not sure what to do? Want to help but just don’t know how to get started? This is the section for you.
-
Triage tickets
If an unreviewed ticket 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 area.
-
Beginner
Look at issues labeled beginner. These are meant to be a great way to get a smooth start and won't put you in front of the most complex parts of the system. These require a few lines of code, and a test or two.
-
Need a challenge?
If you are up to more challenging tasks with bigger scope, then there are a set of issues labeled Feature or Improvement. This issues have a general overview and description of the work required to finish. Make sure the issue has an Accepted label on it first.
-
Write some documentation
The Swahilinux Community strives to write great documentation but it can always be improved. Did you find a typo? Do you think something should be clarified? Go ahead and suggest a documentation change/edit. See also the guide on Buiding and Contributing to Documentation.
How you write this is up to you, but some things you may want to include:
- Let them know if they need to sign a CLA, agree to a DCO, or get any other legal stuff out of the way
- If tests are required for contributions, let them know, and explain how to run the tests
- If you use anything other than GitHub to manage issues (ex. JIRA or Trac), let them know which tools they’ll need to contribute
For something that is bigger than a one or two line fix:
- Create your own fork of the code
- Do the changes in your fork
- If you like the change and think the project could use it:
- Be sure you have followed the code style for the project.
- Sign the Contributor License Agreement, CLA, with the jQuery Foundation.
- Note the jQuery Foundation Code of Conduct.
- Send a pull request indicating that you have a CLA on file.
[source: Requirejs] Need more inspiration? [1] Active Admin [2] Node.js [3] Ember.js
Small contributions such as fixing spelling errors, where the content is small enough to not be considered intellectual property, can be submitted by a contributor as a patch, without a CLA.
As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality or creative thinking. As long as the change does not affect functionality, some likely examples include the following:
- Spelling / grammar fixes
- Typo correction, white space and formatting changes
- Comment clean up
- Bug fixes that change default return values or error codes stored in constants
- Adding logging messages or debugging output
- Changes to ‘metadata’ files like Gemfile, .gitignore, build scripts, etc.
- Moving source files from one directory or package to another
[source: Chef] Need more inspiration? [1] Puppet
At bare minimum, include this sentence:
If you find a security vulnerability, do NOT open an issue. Email XXXX instead.
If you don’t want to use your personal contact information, set up a “security@” email address. Larger projects might have more formal processes for disclosing security, including encrypted communication. (Disclosure: I am not a security expert.)
Any security issues should be submitted directly to security@travis-ci.org In order to determine whether you are dealing with a security issue, ask yourself these two questions:
- Can I access something that's not mine, or something I shouldn't have access to?
- Can I disable something for other people?
If the answer to either of those two questions are "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue, so if you're unsure, just email us at security@travis-ci.org.
[source: Travis CI] Need more inspiration? [1] Celery [2] Express.js
You can even include a template so people can just copy-paste (again, less work for you).
When filing an issue, make sure to answer these five questions:
- What version of Go are you using (go version)?
- What operating system and processor architecture are you using?
- What did you do?
- What did you expect to see?
- What did you see instead? General questions should go to the golang-nuts mailing list instead of the issue tracker. The gophers there will answer or ask you to file an issue if you've tripped over a bug.
[source: Go] Need more inspiration? [1] Celery [2] Atom (includes template)
This information will give contributors context before they make suggestions that may not align with the project’s needs.
The Express philosophy is to provide small, robust tooling for HTTP servers, making it a great solution for single page applications, web sites, hybrids, or public HTTP APIs.
Express does not force you to use any specific ORM or template engine. With support for over 14 template engines via Consolidate.js, you can quickly craft your perfect framework.
[source: Express] Need more inspiration? Active Admin
If there is back-and-forth or signoff required, say so. Ask them to scope the feature, thinking through why it’s needed and how it might work.
If you find yourself wishing for a feature that doesn't exist in Elasticsearch, you are probably not alone. There are bound to be others out there with similar needs. Many of the features that Elasticsearch has today have been added because our users saw the need. Open an issue on our issues list on GitHub which describes the feature you would like to see, why you need it, and how it should work.
[source: Elasticsearch] Need more inspiration? [1] Hoodie [2] Ember.js
Who reviews it? Who needs to sign off before it’s accepted? When should a contributor expect to hear from you? How can contributors get commit access, if at all?
The core team looks at Pull Requests on a regular basis in a weekly triage meeting that we hold in a public Google Hangout. The hangout is announced in the weekly status updates that are sent to the puppet-dev list. Notes are posted to the Puppet Community community-triage repo and include a link to a YouTube recording of the hangout. After feedback has been given we expect responses within two weeks. After two weeks we may close the pull request if it isn't showing any activity.
[source: Puppet] Need more inspiration? [1] Meteor [2] Express.js
If there are other channels you use besides GitHub to discuss contributions, mention them here. You can also list the author, maintainers, and/or contributors here, or set expectations for response time.
You can chat with the core team on https://gitter.im/cucumber/cucumber. We try to have office hours on Fridays.
[source: cucumber-ruby] Need more inspiration? [1] Chef [2] Cookiecutter
These sections are not necessary, but can help streamline the contributions you receive.
Need inspiration? [1] Requirejs [2] Elasticsearch
Need inspiration? [1] Angular [2] Node.js
Need inspiration? [1] StandardIssueLabels [2] Atom