The dev team should have a coherent vision that it pursues and communicates to volunteers. (This is related, to the things I have said in #10 and #13).
If there is no coherent vision, then development will be unfocused and move in essentially random directions. This will reduce the impact of the resources (money, volunteer time) that are spent on said development. Engaging volunteers behind a shared and clear vision will also enthuse them and bring further meaning to what they are doing, resulting in happier volunteers who are more likely to invest more time in SR, and are more likely to attract more volunteers to work on SR.
I have already mentioned splitting the dev team into three separate groups in #8 -- kit, competition software, and competition event software. If this is done, then the three groups can each distinctly define their vision of the things that they are responsible for.
Having a direction that the organisation is heading in is one of the key differences that sets SR apart from other FOSS projects, like GNU Emacs for example. Other projects frequently just accumulate contributions from 'drive-by' contributors, and so move in fairly random directions. SR has goals, and it should use the resources that it has to engage development in specific directions.
The dev team should have a coherent vision that it pursues and communicates to volunteers. (This is related, to the things I have said in #10 and #13).
If there is no coherent vision, then development will be unfocused and move in essentially random directions. This will reduce the impact of the resources (money, volunteer time) that are spent on said development. Engaging volunteers behind a shared and clear vision will also enthuse them and bring further meaning to what they are doing, resulting in happier volunteers who are more likely to invest more time in SR, and are more likely to attract more volunteers to work on SR.
I have already mentioned splitting the dev team into three separate groups in #8 -- kit, competition software, and competition event software. If this is done, then the three groups can each distinctly define their vision of the things that they are responsible for.
Having a direction that the organisation is heading in is one of the key differences that sets SR apart from other FOSS projects, like GNU Emacs for example. Other projects frequently just accumulate contributions from 'drive-by' contributors, and so move in fairly random directions. SR has goals, and it should use the resources that it has to engage development in specific directions.