Merge pull request #25 from nspcc-dev/minor-additions

Minor additions

README.md

@@ -0,0 +1,6 @@
+# NeoSPCC GitHub
+
+This repository contains an organization-wide profile README as well as a set
+of policies describing how organization works and what it expects from its
+contributors. Generic workflows reused by multiple other repositories in the
+organization are also stored here.

git.md

@@ -29,6 +29,22 @@ currently developed ones. Some additional branches MAY be present if they
 can't be merged for some reason yet at the same time they have some historical
 or other value.
 
+## Pull requests
+
+All regular changes are processed via pull requests with review requiring at
+least one approval. Direct pushes to the master branch by those who have
+sufficient priviledges to do that can only be done in exceptional cases or
+when some process specifically requires that (like some release processes).
+PRs can be merged without an approval in infrastructure-related repositories
+(like Ansible roles) if they're otherwise conformant to the requirements
+described here and if not merging them can affect production systems.
+
+PRs can have a set of commits if they're related to the same problem (like
+different steps to solve some issue) or the same component/code area (like
+error message typo fix and logic change nearby), however different problems
+(like UI typo fix and build action improvement) shouldn't be mixed in a single
+PR.
+
 ## Commits
 
 The basic unit of any accepted work is a commit (patch). Any work is accepted

project-management.md

@@ -60,3 +60,18 @@ issues get a set of corresponding PR/commit links automatically and nothing
 special is required. However if an issue is closed manually, there MUST be
 a comment describing how and where it's fixed or why it shouldn't/can't be
 fixed.
+
+## Documentation
+
+Each project MUST have a README file describing with brief introduction and
+minimal instructions on how to use it for what purposes.
+
+Each project that has releases MUST have a release instruction in its documents.
+
+Each project with releases MUST have a CHANGELOG describing changes between
+them. This CHANGELOG MUST describe configuration changes if any.
+
+Each project MUST have a LICENSE file with license for its contents.
+
+If project has any runtime dependencies on other projects, there has to be a
+table with compatible versions of this project and its dependencies.