1About development
2=================
3
4Dev team
5--------
6
7There is a "core dev team" (*mic_e*, *JJ*, *zuntrax*, but there's more)
8who work on the project in their free time,
9but since we all have other life-originating interrupts and fluctuating motivation,
10our activity will alternate equally over time (just take a look at the commit statistics).
11We "core devs" have known each other personally for a long time;
12thus, communication happens mostly over private channels (XMPP, Mumble, maybe even real life).
13
14
15Development workflow
16--------------------
17
18Many contributions originate from discussions on the IRC channel,
19or an issue on the [issue tracker](https://github.com/sfttech/openage/issues).
20
21The pull requests are then open for review by everybody.
22If the pull request author thinks that their goals aren't met yet,
23it is tagged with `[WIP] $title`.
24The author removes it once the goals are met.
25
26In the big picture, we're working on completing those WIP pull requests,
27user-submitted issues or the next milestone.
28In reality however, we're often working on unrelated stuff that is not covered
29by any milestone (buildsystem, infrastructure, ...),
30just convenient to implement, or needed right now.
31
32We're releasing early and often: whenever we add/improve a feature or
33fix a bug and the code still compiles, we push the code to the github master.
34Once significant changes have accumulated,
35we tag that commit with a new minor version.
36
37We don't have dedicated "subsystem maintainers" yet.
38You can track down the person who did things with `git log` or `git blame`.
39
40
41Contributing
42------------
43
44All sorts of contributions are welcome, including
45
46 - feature requests
47 - bug reports
48 - code/doc typo fixes
49 - code style fixes when our code doesn't conform to our own style guide (yes, that happens.)
50 - bug fixes
51 - new features
52 - game assets under a free license
53 - raytraced intro cutscenes
54 - whatever else you can think of
55
56But read [contributing.md](/doc/contributing.md) first to learn about the contribution workflow/requirements.
57
58As always, join the IRC channel (`freenode.net#sfttech`) and discuss your ideas.
59
60
61Code philosophy
62---------------
63
64 - If upstream code (other parts of openage, other libraries,
65   or even the compilers) doesn't work or is missing some feature,
66   _report / fix it_! We contributed to compilers, cmake, Python, Cython and more because of openage.
67 - Do things properly, not quickly. It takes research, time and maybe even upstream fixes, but it's worth it.
68 - If you absolutely _must_ use a dirty hack (e.g. because you're waiting for upstream to fix it), write a TODO message with an explanation.
69 - Regularly review old code to find rusty parts. Remove them, rewrite them, refactor them or at least update the comments.
70 - The project is in development. Don't be shy about adding, removing and changing interfaces, but tell other people if you break their WIP stuff.
71 - Others can't look into your brain. Document your stuff:
72   - Explanations about inner workings algorithms and data structures should be comments in the source code.
73   - Design decisions, API specification, rants about mathematical concepts and the like are explained in `doc/`.
74