Result for Question 3

Responses Shown

Hide Responses

Go to Question 2
Go back to the List of Questions
Go to Question 4

3.

What work practices and culture should be promoted?

3.1. Sense of responsibility
Terence There should be a chain of responsibility for each addition to the
code
3.2. Measurement of quality of code
Terence There should be objective measures of code maturity, and specific
prioritization for new features, etc.
3.3. Prioritization of new features
Terence There should be objective measures of code maturity, and specific
prioritization for new features, etc.
3.4. Reinforcing explicit development roles
Terence Explicit descriptions (suggestions?) of development roles needed
to fill for project development.
3.5. Reuse of existing source code
Mark reuse of existing code by developers! sourceforge in particular fails horribly to promote a culture of reuse, by collecting and "ranking" statistics on such misguided metrics as "number of new commits to CVS". since sourceforge is a commercial venture, they want to promote the multiplicity of projects, but this behaviour undermines the central benefit of free software: reuse and modification of others' code.

clarification: the "number of new commits to CVS" is a very sourceforge-specific example, and is meaningless as a general survey concept. they also, for example, have a "new projects this week" statistic which is troubling. what I really wanted to get at was: don't focus the site purely on the "creation of new software" (though this is perhaps the most fun part of programming) but rather on "finding software which solves your problem". e.g. make it easy for one project to depend on another (or several others), make it easy to cross-reference documentation between projects, etc.
3.6. Do not focus on the volume of software created, but usefulness
Mark reuse of existing code by developers! sourceforge in particular fails horribly to promote a culture of reuse, by collecting and "ranking" statistics on such misguided metrics as "number of new commits to CVS". since sourceforge is a commercial venture, they want to promote the multiplicity of projects, but this behaviour undermines the central benefit of free software: reuse and modification of others' code.

clarification: the "number of new commits to CVS" is a very sourceforge-specific example, and is meaningless as a general survey concept. they also, for example, have a "new projects this week" statistic which is troubling. what I really wanted to get at was: don't focus the site purely on the "creation of new software" (though this is perhaps the most fun part of programming) but rather on "finding software which solves your problem". e.g. make it easy for one project to depend on another (or several others), make it easy to cross-reference documentation between projects, etc.
3.7. Emphasis on history, reuse old resources
Mark in general, "history" rather than "the future". too many documents are lost in obscure FTP archives. too many new projects are founded to produce programs which have been made already. nowhere near enough emphasis is placed on "reading and learning from the past". free software is as relevant as an academic tradition as it is as a commercial force, if not moreso.
3.8. Computer science/software engineering knowledge
Mark a respect for theoretical CS. there is essentially zero theoretical learning material on most infrastructure sites. any documents they collect are of the ground level, "how to" sort, possibly in cookbook or "code fragment" form. it is implied that all one needs to learn is "how to write C, and how to use CVS" and everything else is boring or unimportant.
Joanne What 'should be' promoted? All good software engineering techniques: requirements elicitation and specification, design, coding, testing.
3.9. Creating a public library atomsphere, giving users as much freedom as possible and staying out of the users' way
Mark staying out of the user's way. nothing is more annoying than a paternalistic site that tries to impose the "right" process on its users. an infrasturcture site ideally resembles a public library or community center: lots to read, see and do, minimal procedure required for just browsing. all facilities should be linked off the first page, accessible through email-only or shell-only interfaces, and require no "registration" or special click-through paths to operate.

expansion: "public library atmosphere". anonymous, focused on research, browsable (sourceforge has got the browsable code portion right, but for example there is no automatic facility for formatting a project's documentation for the web, so a visitor is unlikely to read it)
3.10. Documentation of source code and standards in writing style
Joseph commenting source code
Gabriel Adhere to commonly agreed upon coding and writing standards
3.11. Distributed style of development and decentralised decision-making
Jacob collborative and distribtuted software development
Patrick decentralised decision-making - necessary for scaling to large projects, but also important for encouraging developer involvement
3.12. Welcome help from less skilled developers and understand their potential to become high skilled developers
Schulhoff Legitimate Peripheral Participation - Less skilled developers must be allowed to participate at their own level. Less skilled developers must be viewed as potential high skilled developers, given the time to evolve.
Brendan openness as to skills and time commitments
3.13. Tolerance, respect and patience
Joanne The culture would have to be one of tolerance. Most open source software is still done by volunteers (who have other jobs). Deadlines must remain flexible. Teleconferencing must be at a mutually agreed upon time (people could be and probably will be in different time zones). Also, the more people working on a project, the more ideas will be generated. All participant's should be listened to. You get a better product and happier participants.
Phil respect other people
Brendan tolerance toward others particularly across languages and cultures
Brendan patience but firmness
4 Responses
3.14. Awareness of different culture and language background
Schulhoff Acknowledgement of developers different cultural and technical backgrounds as a positive element - very different from corporate monocultures.
Brendan tolerance toward others particularly across languages and cultures
3.15. Awareness of different technology background
Schulhoff Acknowledgement of developers different cultural and technical backgrounds as a positive element - very different from corporate monocultures.
3.16. Listening to others
Joanne The culture would have to be one of tolerance. Most open source software is still done by volunteers (who have other jobs). Deadlines must remain flexible. Teleconferencing must be at a mutually agreed upon time (people could be and probably will be in different time zones). Also, the more people working on a project, the more ideas will be generated. All participant's should be listened to. You get a better product and happier participants.
3.17. Flexibility towards volunteers
Joanne The culture would have to be one of tolerance. Most open source software is still done by volunteers (who have other jobs). Deadlines must remain flexible. Teleconferencing must be at a mutually agreed upon time (people could be and probably will be in different time zones). Also, the more people working on a project, the more ideas will be generated. All participant's should be listened to. You get a better product and happier participants.
Brendan openness as to skills and time commitments
3.18. The value of heterogeneity, differences as assets
Schulhoff Acknowledgement of developers different cultural and technical backgrounds as a positive element - very different from corporate monocultures.
Alvin They shouldn't promote any particular practice. The heterogeneity of approaches is one of the strengths of the way things are done without these infrastructure sites.
3.19. Nothing should be 'promoted'.
Alvin They shouldn't promote any particular practice. The heterogeneity of approaches is one of the strengths of the way things are done without these infrastructure sites.
3.20. Openness in attitude, no hidden agenda
Phil everything should be open, no hidden agenda
Patrick transparency - openness about procedures and policies
3.21. Openness in procedures and policies
Patrick transparency - openness about procedures and policies
3.22. Cooperation and collaboration, encourage involvement of developers to share the load of development
Jacob collborative and distribtuted software development
Patrick decentralised decision-making - necessary for scaling to large projects, but also important for encouraging developer involvement
Brendan cooperation
Brendan sharing the load
Luke Inviting environment: This means that the tools must be easy to use, not take too much time away from actual develpoment and allow for easy addition to becoming a project member.
5 Responses
3.23. Firmness
Brendan patience but firmness
3.24. Keeping promises
Brendan fulfilling contracts

clarification: doing what you say that you will do and expecting others to do what they say they will do
3.25. Avoid force
Brendan avoid force
3.26. Critique for the sake of the task
Brendan critique for the sake of the task

clarification: (previous answer: critique for the same of the task) mistyping on my part. should be critique for the sake of the task. that is being constructively critical of products, procedures and people including task leaders
3.27. Jane Jacob's systems of survival's commercial moral syndrome
Brendan jane jacob's systems of survival's commercial moral syndrome
3.28. Using centralised repository for source code
Dave Checking code into a common repository.
3.29. To include automated building and testing facilities in releases
Mark to provide automated building and testing facilities
Dave Providing release build testing.
3.30. Easy to use, high usability
Luke Inviting environment: This means that the tools must be easy to use, not take too much time away from actual develpoment and allow for easy addition to becoming a project member.
Noah Usability.
3.31. Flexibility in tools for rapid project administration
Luke Flexibility: Open Source projects are dynamic and can be very fast moving and have the potential to break new ground. The tools must then be flexible and allow the project admins as much control over the tools as possible.
3.32. A system to attribute credit
Luke Credit: There must be a kudo system to credit active contributors
3.33. Standards in software design
Noah Software Design Patterns.
3.34. The practices of Extreme Programming
Noah Development practices along the lines of Extreme Programming.
3.35. Clarity, simpleness of code
Noah Clarity, simpleness of code.
3.36. Standards coding style
Noah Strict adherence to the selecetd style for the programming language used.
Gabriel Adhere to commonly agreed upon coding and writing standards
3.37. Fun and good spirit and hope
Leslie Fun and good spirit and hope
3.38. Frequent submissions of contributions
Gabriel Frequent submissions of contributions

Hide Responses

Go to Question 2
Go back to the List of Questions
Go to Question 4

Go to Infrastructure For Hosting Open Source Project (IFHOSP) Delphi Survey
Generated On: 27 Sep 2002