Thank you for contributing to the Gibson County Ambulance Service Website. This website will be very narrow in scope, due to the exacting requirements of their work and pay schedules.
This document should help to communicate what is expected of you, the contributor, as well as the manager(s) of this project. If you have any questions, please bring them to the attention of the project manager. The manager will strive to answer your question in a courtious and timely manner.
As with any project, there are many tasks which must be completed to see a successful outcome. This project is no different. As recorded in README.md, this project was started by a paramedic with very little programming experience. He used this project as a tool for expanding his horizons and to gain experience in programming. If you are new to software development, please feel free to pick a bug report or project and work on it. As the base of this project was written by an inexperienced programmer, there in undoubtedly many things that can be accomplished better, faster, or more efficiently. If you see any such situations, file a pull request with the proposed changes.
Even if your forte is not programming, there are many areas in which your services would be most valuable. Some other examples are: Improving documentation, bug triaging, writing tutorials, web page design (even if it is simply a sketch of improvements over the current). Keep an open mind.
Due to the narrow scope of this project, it is suggested that you check with the project manager prior to submitting work not suggested by one of the bug reports or listed as one of the projects. It would be of no use to you nor to the project for you to invest time into code which is not appropriate for the project and therefore would be rejected.
As of this writing, this project does not have any official means of communication other than the issue tracker. While this method is not ideal, it should serve the purpose until a better solution is presented and accepted.
Responsibilities
- Ensure cross-platform compatibility for every change that's accepted. Windows, Mac, Debian & Ubuntu Linux.
- Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
- Don't add any classes to the codebase unless absolutely needed. Err on the side of using functions.
- Keep feature versions as small as possible, preferably one new feature per version.
- Be welcoming to newcomers and encourage diverse new contributors from all backgrounds.
Unsure where to begin contributing to this project? You can start by looking through these beginner and help-wanted issues:
Beginner issues - issues which should only require a few lines of code, and a test or two. Help wanted issues - issues which should be a bit more involved than beginner issues.
Here are a couple of friendly tutorials you can include: http://makeapullrequest.com/ and http://www.firsttimersonly.com/
Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.
As a side note, it helps to use newcomer-friendly language throughout the rest of your document. Here are a couple of examples from Active Admin:
At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first 😸
If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge.
If you find a security vulnerability, do NOT open an issue. Email XXXX instead. (Email to be added later)
Any security issues should be submitted directly to XXXX. (Email to be added later) 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 XXXX.
When filing an issue, make sure to answer these five questions:
- What web browser are you using? (Name and version number)
- What operating system and processor architecture are you using?
- What did you do? (Steps to recreate the bug)
- What did you expect to see?
- What did you see instead?
If you have an idea for a feature or an enhancement, please use the issue tracker system with the appropriate label. If you would like to code the feature or enhancement, the project manager will give you the go ahead if the request fits the needs of the project. Explain in detail why you think the enhancement is needed, how it will improve the project, and how it should work.
The core team looks at Pull Requests on a regular basis. 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.