Because any code we release reflects on the company as a whole, and on each of us as individuals, we need to have a set of guidelines that we all stand behind so that we are assured we are all happy with the code that gets released.
This guide is broken up into several parts:
-
Licensing
-
Attribution
-
Internal peer review
-
Release checklist
Every project we release should contain a copy of our license text from the very beginning. The license should be in the root directory of each project, in a file called ‘LICENSE’. The license we use is the Apache License v2:
Copyright [yyyy] mDialog Corp (http://mdialog.com/) Copyright [yyyy] [contributor 1] Copyright [yyyy] [contributor 2] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Make sure you update the copyright notices, there should be one copyright notice for each contributor. Ideally each contributor’s email address would be listed along with their name.
The Readme for any project we release also needs to contain a line toward the bottom of the file quickly listing what license the project is released under:
This project is released under the Apache License v2, for more details see the 'LICENSE' file.
Each project must contain a listing of all the people that have contributed to the project, as well as a line that gives mDialog credit for the project. eg (in RDOC format):
Contributors:: {Contributor Uno}[mailto:[email protected]], {Contributor Dos}[mailto:[email protected]] {An mDialog Project.}[http://mdialog.com/]
Before any project or update is released the code must go through a minimal internal peer review process:
-
If the code is for a new project, the project must be approved by management and the development team.
-
At least one other person on the development team must read over and sign-off on the code.
-
A note about the new code should be sent out after its release via Campfire or group email so the rest of the team gets a second chance to review or veto the code.
-
Has it been approved by management and by the development team?
-
Does it have the correct license text?
-
Does it have a meaningful README?
-
Has the code been through internal peer review?
-
Does the project structure meet best practices for projects of this type?
-
Has the release of the project been OK’d by any related third-party vendors?
-
Does the project list all its contributors?
-
Does the project disclose any third-party open-source code that it contains?
-
Has the project been vetted to make sure it does not contain any third-party GPL code?
-
Has the code been tested, does it have automated tests associated with it?
-
Is the code something we are proud to release?
-
Does the code reflect our values as a team?
-
Has the code been through internal peer review?
-
Has the code been tested, does it have automated tests associated with it?
-
Is the code something we are proud to release?
-
Does the code reflect our values as a team?
-
Has the license text been updated to list new contributors?
-
Does the project disclose any third-party open-source code that it contains?
-
Has the code been vetted to make sure it contains no GPL’d code?
-
Has the README been updated to reflect the code changes?
-
Has the project version number been updated to reflect the change?
This project is released under the Apache License v2, for more details see the ‘LICENSE’ file.
- Contributors