3. |
What work practices and culture should be promoted? |
Totally Irrelevant |
Extremely Relevant |
|
|
3.1
|
Sense of responsibility |
|
|
3.2
|
Measurement of quality of code
Comment: |
Measuring the quality of code? You've got to be kidding me. It's hard enough deciding what "quality code" even is.
|
|
|
|
3.3
|
Prioritization of new features |
|
|
3.4
|
Reinforcing explicit development roles
Comment: |
It's good for 'roles' to not be taken too stringently in FS/OS. Many of us are 'all-purpose' developers. The diversity we are exposed to can't let us get stuck in one 'role'.
|
|
|
|
3.5
|
Reuse of existing source code |
|
|
3.6
|
Do not focus on the volume of software created, but usefulness
Comment: |
A lot of software is created merely to 'learn.'
|
|
|
|
3.7
|
Emphasis on history, reuse old resources |
|
|
3.8
|
Computer science/software engineering knowledge
Comment: |
Helps a great deal, but is not necessary.
|
|
|
|
3.9
|
Creating a public library atomsphere, giving users as much freedom as possible and staying out of the users' way |
|
|
3.10
|
Documentation of source code and standards in writing style |
|
|
3.11
|
Distributed style of development and decentralised decision-making |
|
|
3.12
|
Welcome help from less skilled developers and understand their potential to become high skilled developers
Comment: |
Without this, we end up with the cathedral mentality.
|
|
|
|
3.13
|
Tolerance, respect and patience |
|
|
3.14
|
Awareness of different culture and language background |
|
|
3.15
|
Awareness of different technology background
Comment: |
FS/OS is a good deal about learning, and being aware of different technologies helps learning a lot.
|
|
|
|
3.16
|
Listening to others |
|
|
3.17
|
Flexibility towards volunteers |
|
|
3.18
|
The value of heterogeneity, differences as assets |
|
|
3.19
|
Nothing should be 'promoted'. |
|
|
3.20
|
Openness in attitude, no hidden agenda |
|
|
3.21
|
Openness in procedures and policies |
|
|
3.22
|
Cooperation and collaboration, encourage involvement of developers to share the load of development
Comment: |
Very tough thing to do; I'm not sure how/if one should really go about this.
|
|
|
|
3.23
|
Firmness
Comment: |
Too much firmness can cause objects to 'shatter' (fork)
|
|
|
|
3.24
|
Keeping promises |
|
|
3.25
|
Avoid force |
No Comment |
|
3.26
|
Critique for the sake of the task |
|
|
3.27
|
Jane Jacob's systems of survival's commercial moral syndrome |
No Comment |
|
3.28
|
Using centralised repository for source code |
|
|
3.29
|
To include automated building and testing facilities in releases |
|
|
3.30
|
Easy to use, high usability |
|
|
3.31
|
Flexibility in tools for rapid project administration |
|
|
3.32
|
A system to attribute credit
Comment: |
Since many of us aren't being paid, it helps a lot if we get credit in the 'noosphere', as ERS has written about.
|
|
|
|
3.33
|
Standards in software design |
|
|
3.34
|
The practices of Extreme Programming |
|
|
3.35
|
Clarity, simpleness of code |
|
|
3.36
|
Standards coding style |
|
|
3.37
|
Fun and good spirit and hope |
|
|
3.38
|
Frequent submissions of contributions
Comment: |
Having things move fast is one of the things that people like about FS/OS. Without it, users lose interest in projects, and following that, developers also lose interest.
|
|
|