Documentation

Releases

Meetings Summary

1. Documentation/Draft prior to implementation.
2. Who ever works well get more critical tasks.
3. Always code review.
4. Always add tests.
5. We like stable interfaces, stateless functions and immutable objects.

1. We assign a task to a person only in the case where this person actively works on this issue.
2. Everyone may open issues, for bugs or feature as they wish. All issues are opened unassigned, without any labels and no milestone set.
3. For now only the moderator will assign the person (after discussing, via email, the issue together), set a label (if needed) and assign to a milestone (if needed).
4. Each time the assigned person is changed, the issue should be shortly commented, i.e. "no time to work this week on this issue" or "please review the following code ..." or "I have committed the fix , please validate and close".
5. When the issue becomes depended on other issue or blocked for some reason, the assigned person should comment shortly, i.e., "Cannot solve this until issue #101 will be solved" or "Unable to solve until the new servers arrive" and unassign himself.
6. We will use only one milestone which will include all issues which are being actively worked on. All other issues (low priority or best effort) will be without milestone.
7. We have only one label named 'Critical' which means this issue is a show-stopper and should be handled as soon as possible as it blocks others or delays the next release.

1. Someone opens an issue, add description, exception details or logs, suggestions, etc.
2. Moderator discusses this issue with the person opened it and with potential person who will solve this issue and assignes this person to solve the issue.
3. After solving the issue, it is reassigned to someone else for code review.
4. After code review the issue is reassigned to the person opened the issue to validate it's done.
5. Person who opened the issue validates and closes the issue.

If in the process there is any problem, the issue is assigned to moderator with proper short comment.

1. All gems are released in a standard simplest way using Semantic Versioning.
2. Basically a release is any content_server gem version which was properly tested.
3. The release should depend on specific gem versions. We should validate that sub-gems will use same gems as content_server uses.
4. Documentation which should be included for each release: a. Clean machine run/install. b. How to update from previous version.
5. We should mark in each releases in git.

Documentation.