This repository contains company-wide guidelines on writing code and organizing workflow. If Kowainik member doesn’t know how some part of his/her work should be done he/she should refer to this guide. If some part of the workflow is not clear from this document — feel free to open an issue to this repository. But, of course, everyone should read this README first.
Slack messenger is currently used as primary tool for communication (unless better options discovered). Workspace:
It’s better to share ideas and insights under relevant issues for projects but if there’s no such issue or such discussion is rather informal, Slack can be used for communication between team members. Also it uses integration with different useful applications.
Below is set of general rules for communication in slack:
NO PRIVATE CHANNELS.
Project-based discussion. Every repository
kowainik/reposhould have two channels in Slack:
If you want to add GitHub integration for this repo you need to type the following command in #repo-apps channel
/github subscribe kowainik/repo reviews comments branches commits:all
Thread-based discussion. Try to follow topic-based discussion: post some message to channel, reply in thread to this message without duplicating messages to channel.
Channel topics. If this is a project channel then topic should contain link to project sources.
Version control system🔗
Git version control system based on GitHub is used.
TODO: experiment with Pijul at some moment in future.
Issues and branches🔗
- Work should be done under corresponding GitHub issue. If such issue doesn’t exist: create it.
- Always discuss work under corresponding GitHub issue before doing this issue. If you see multiple ways to do something — discuss with somebody under issue comments section how to do this. If you’re not sure that there’s only one way to do the thing — discuss with somebody under issue comments section how to do this. In perfect case scenario each issue should contain some plan how to do this issue.
masterbranch should be stable, always compilable and working.
- Do your work for some issue under separate branch forked from
- Name your branch as
username/issueId-short-description. For example:
- You shouldn’t fix multiple issues in a single branch.
- Use this guide for commit messages.
- Every meaningful commit should contain issue number in square brackets before message.
[#6] Describe basic guidelines
Fix the typo
[skip ci]tag to the end of the commit.
Change README.md [skip ci]
- Open PR if you:
- Finished your work on the issue
- Want to share work with others (for example you can open PR if you need somebody to look and to get advice for continue working on it)
wiplabel to your PR if work is not finished.
- Add issue number at the title of PR in square brackets (just like in commit messages).
- Request review from at least two people in team.
- Pull request can be merged to
masteronly if there’re two approvals for this PR.
- Resolve all conflicts using only
git rebasecommand to make history clean.
- If you’re the second person who approves the PR you should click on the
Squash and Mergebutton.
cabalbuild tool with
stackas a main build tool. But it’s desired to support both of them on CI.
- Every project should contain the following files in addition to code:
- Use PVP versioning for projects.
TODO: What about Windows CI?