1 |
The 30/05/12, Grant wrote: |
2 |
|
3 |
> So if I see a way that their coding could be improved (faster |
4 |
> execution, greater legibility, etc) I just keep quiet about it? |
5 |
|
6 |
Improvements is only one aspect of where to focus the efforts. |
7 |
|
8 |
> How often should I read their code? I was planning on reading it a lot. |
9 |
|
10 |
In small teams, these tasks (including making releases) are usually done |
11 |
by the software maintainer. To know what to do, you should be clear |
12 |
about who will be in charge of releasing the software. A SVC is |
13 |
*required* and the tool choice should be a team choice. |
14 |
|
15 |
Once done and roles assigned, it will be really easy for you to know |
16 |
what you can/should do or not. Anybody can act/interact as different |
17 |
role as long as the role is well defined (e.g. while reviewing code, you |
18 |
do reviewing code /only/ and might discuss the design choices but the |
19 |
final technical decision must stay in the hands of the software |
20 |
maintainer). |
21 |
|
22 |
FMPOV the key role is the maintainer. The job requires both good |
23 |
technical knowlegde and a large project view. |
24 |
|
25 |
-- |
26 |
Nicolas Sebrecht |