Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a section about cookiecutter template updates #75

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
+12 −3
Draft

Add a section about cookiecutter template updates #75

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0068fd0
Add a section about cookiecutter template updates
vbaltrusaitis-reef Sep 3, 2022
f5150d5
Add the motivation behind template update policy
vbaltrusaitis-reef Sep 6, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 12 additions & 3 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -414,7 +414,16 @@ Please follow these guidelines when copying code:
- Please mention the license of the source code which is copied


### 7.3 Conventions
### 7.3 Django cookiecutter template

We use an internally-developed [cookiecutter template](https://github.com/reef-technologies/cookiecutter-rt-django/) for our Django projects. When we start a new project, the template empowers us to immediately focus on the core of the business problems instead of spending time on set-up tasks. It also provides a common base of libraries, dev-ops tools and conventions that Reef developers get familiar with. Over time, we improve the template - we update dependencies, add new features, fix issues. Therefore, it is important not only to start new projects using the template but also to port template updates to existing projects. This leads to two rules that we follow:

- New Django projects must use the template. Any exceptions must be discussed with the team beforehand.
- When we make a change to any of our template-based projects, we also update them to follow the newest version of the template.

This is important because we sometimes fix bugs in the template or we workaround an issue with deployment or with one of the dependencies and then we forget about it. If someone comes in two years later, learns the template and adjusts an old project without updating the template, he might run into one of those old problems that have been fixed a year ago - but it'd be hard to know if any such issue might affect the system in question and checking this is an expensive and a bit pointless process. It's easier to just update the template in a side effect of adding a feature/fixing a bug.

vbaltrusaitis-reef marked this conversation as resolved.
Show resolved Hide resolved
### 7.4 Conventions

We _typically_ follow the conventions listed below. Not always. The list seems long, but it really isn't.

Expand Down Expand Up @@ -484,7 +493,7 @@ https://sipb.mit.edu/doc/safe-shell/

See the next section

### 7.4 Restricted patterns
### 7.5 Restricted patterns

Whenever someone would like to use a pattern listed below, we have decided that they will get an opinion from a design reviewer __before__ writing the code. The restricted technologies are:
1. Django GFK (generic foreign key)
Expand All @@ -498,7 +507,7 @@ The reasoning behind this is that we usually prefer for the code to be structure

See also: https://github.com/reef-technologies/python-review-zoo/

### 7.5 Holidays (days off)
### 7.6 Holidays (days off)

Whenever you're taking some days off, it's important to let other team members know, so that work can be
planned and client expectations managed.
Expand Down