Answer from Mark

Summary Hidden

Show Summary

Go to List of Participants

Mark regards himself/herself as:

1. What are the objectives of an IFHOSP site?

1.1 to facilitate communication between geographically disparate developers
1.2 to facilitate shared, concurrent, version-controlled development of source code and documentation by multiple developers
1.3 to reliably archive communication, documentation, and source code for retrieval by the public
1.4 to provide automated building and testing facilities
1.5 to act as a central location for developers to discover, browse and select from existing code bases, rather than rewriting.

2. What tools can be employed on an IFHOSP site and what are the important features and usability factors for each of them?

Tool 1: cvs   

2.1 Brief Description

concurrent version system; client/server source control system

2.1.2 What are the important features of this tools?

2.1.2.1 established standard, widely available and understood
2.1.2.2 client/server, works over a network
2.1.2.3 permits concurrent development without locking

2.1.3 What are the important usability factors of this tools?

2.1.3.1 Learnability : It is easy and intuitive to learn how to operate the site
2.1.3.2 Memorability : It is easy to remember how to operate the site
2.1.3.3 Simple and natural dialogue : Interaction between computer and users is as simple as possible and information in the interaction is presented in natural and logical fashion
2.1.3.4 Speak the users' language : During the interaction between computer and users, terms and concepts that are familiar to users are used rather than system-oriented terms

Tool 2: qmail + ezmlm   

2.2 Brief Description

mail transport and mailing list management system

2.2.2 What are the important features of this tools?

2.2.2.1 speed
2.2.2.2 reliability
2.2.2.3 security

2.2.3 What are the important usability factors of this tools?

2.2.3.1 Efficiency : The users can achieve a level of high productivity when using the site
2.2.3.2 Few Errors : There are very few number of operational errors on site
2.2.3.3 Security : The site is secure
2.2.3.4 Searchable : The content within the site can be accessed by a search mechanism on site
2.2.3.5 Speak the users' language : During the interaction between computer and users, terms and concepts that are familiar to users are used rather than system-oriented terms

Tool 3: wiki   

2.3 Brief Description

a collaborative, unstructured document editing and repository system

2.3.2 What are the important features of this tools?

2.3.2.1 simplicity. easy to add new documents, change documents, point to documents, modify others' work.

2.3.3 What are the important usability factors of this tools?

2.3.3.1 Ease of Navigation : The information is in a structure that is easy to navigate
2.3.3.2 Searchable : The content within the site can be accessed by a search mechanism on site
2.3.3.3 Learnability : It is easy and intuitive to learn how to operate the site
2.3.3.4 Simple and natural dialogue : Interaction between computer and users is as simple as possible and information in the interaction is presented in natural and logical fashion

Tool 4: ssh   

2.4 Brief Description

necessary secure access method

2.4.2 What are the important features of this tools?

2.4.2.1 No Comment.

2.4.3 What are the important usability factors of this tools?

2.4.3.1 No Comment.

3. What work practices and culture should be promoted?

3.1 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.2 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.3 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.
3.4 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)

4. What are factors that movitate users to use an IFHOSP site?

4.1 availability and reliability
4.2 speed
4.3 capacity (memory, storage, cpu)

5. What are barriers that prevent users from using an IFHOSP site?

5.1 downtime
5.2 inaccessibility
5.3 incompatibility

clarification: the site may impose a set of tools, a community organization structure, and a development methodology which is not readily compatible with the way a user is already developing their software. this will prevent the user from moving from their private facility to the IFHOSP site. the IFHOSP site must be willing to provide "partial" service using the user's preferred tools and methodology, at least as a stopgap until the user converts to the IFHOSP site's preferred tools and methodology.
5.4 unresponsive administrators
5.5 low capacity
5.6 slow connection

6. What are the positive results for users in using an IFHOSP site?

6.1 increase in developer <-> repository source code interaction,
with corresponding decrease in developer <-> developer source
code interaction

clarification: developers send patches to one another (not just with the project leader) and produce multiple, personal, non-synchronized versions of their software when they do not have a repository to work from.
6.2 increase in intra-group communication
6.3 attraction of interested third parties
6.4 reliable point of storage and distribution for software, documents

7. What are the negative results for users in using an IFHOSP site?

7.1 possible loss of control over own work. administrators must be completely "hands off" the development, and always provide complete mirroring/withdrawl paths for users of the site.
7.2 possible extra "collaboration" with unwanted parties ("back-seat programmers", trolls). ability to operate private or semi-private developer groups necessary.

clarification: the ability to have private groups is a necessity _imposed_ by the negative factor of participation by unwanted extra developers. the ability to have private groups is _not_ a negative result of using the IFHOSP site itself.
7.3 increased instances of forking and/or "reinvention of the wheel", due to lower energy requirement for setting up "project" areas on infrastructure site. browsing existing code must be exceptionally well facilitated.

8. What are factors that motivate adminstrators to setup or maintain an IFHOSP site?

8.1 No Comment.

9. What are barriers that prevent adminstrators from setting up or maintaining an IFHOSP site?

9.1 No Comment.

10. What are the positive results for adminstrators in setting up or maintaining an IFHOSP site?

10.1 No Comment.

11. What are the negative results for adminstrators in setting up or maintaining an IFHOSP site?

11.1 No Comment.

12. What are other important issues in IFHOSP?

12.1 developing a coherent, reasonable plan for expanding the site into a "federation" or mirror-network of multiple sites, not all of which are under the original site-owner's control. central points of failure (and administrative control) make programmers suspicious.
12.2 maintaining a commitment to hosting only those projects which are under a sufficiently liberal license.
12.3 using the site as a "marketing tool" to encourage non-free software developers to try developing in the open, under a good license.


Show Summary

Go to List of Participants


Generated On: 27 Sep 2002