head	1.3;
access;
symbols
	dlr:1.1.1
	TIGRIS_0_9_2_4:1.1
	TIGRIS_0_9_2_3:1.1
	HELM_PEER_PORT_BRANCH:1.1.1.1
	TURBINE_PEER:1.1
	TIGRIS_0_9_2_1:1.1
	TIGRIS_0_9_2:1.1.0.6
	TIGRIS_0_8_4:1.1.0.4
	TIGRIS_0_9_0:1.1.0.2;
locks; strict;
comment	@# @;


1.3
date	2001.02.26.23.40.58;	author lori;	state dead;
branches;
next	1.2;

1.2
date	2001.02.11.18.29.47;	author jrobbins;	state Exp;
branches;
next	1.1;

1.1
date	2000.12.30.23.22.00;	author jrobbins;	state Exp;
branches
	1.1.1.1
	1.1.4.1
	1.1.8.1;
next	;

1.1.1.1
date	2001.02.21.00.31.54;	author dlr;	state Exp;
branches;
next	;

1.1.4.1
date	2001.01.16.00.17.44;	author susank;	state Exp;
branches;
next	;

1.1.8.1
date	2001.02.17.18.39.15;	author edk;	state Exp;
branches;
next	;


desc
@@


1.3
log
@removed file; obsoleted by 1.0 help
@
text
@<HTML>
<HEAD>

<TITLE>Open Source Best Practices</TITLE>

</HEAD>
<BODY>
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
    <TD class="Header" nowrap>Key Open Source "Best Practices" supported on this site</TD>  
  </TR>
</TABLE>


<TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2" BORDER="0" width="100%">
  <TR>
    <TD class="PlainText" VALIGN="top" >
     <P>


<P>
Software engineering practices are key to any large development
project.  This site provides a home to conduct open source or
collaborative software projects integrated with a set of hosted
development tools to facilitate project teams adopting the "best
practices" that have proven themselves in the open source community.
<BR>
<BR>

<span class="InputHeader">Technical Communication</span>

<P>Software developers spend a large part of their time communicating
with each other. Clear and effective technical communications are
needed to keep the team in synch and to allow individuals with key
knowledge to apply that knowledge where it is needed.

<P>One tenet of the open source community is that technical
communications should take place in public forums. Mailing lists are
the backbone of open source communications. Beyond that, open source
projects need support for precisely communicating technical details
and for group decision-making.  
<BR>
<BR>

<span class="InputHeader">Version Control, Document Management, and Distribution </span>

<P>Every software development project needs version control. Open
source projects need strong and flexible support for many concurrent
developers working on overlapping sets of files. Open source projects
also need standard templates for design documents, technical
documentation, and end user documentation.

<P>A well-organized project should facilitate distributing these
documents. But, the nature of open source projects demands that these
files are globally accessible, and that administrative overhead be
minimized and responsibility be spread out over the members of the
development community.  
<BR>
<BR>

<span class="InputHeader">Quality Assurance</span>

<P>Open source software products have achieved a remarkable degree of
quality. This is something that the closed source development world
has found to be one of the most difficult and costly aspects of
software development.

<P>Open source software is high quality for three main reasons:<BR>

<OL>

<LI>Developers are self-selected by their interest and knowledge of
the application domain.

<LI>Requirements are tacitly understood by developers who are
themselves users of the software.

<LI>Technical communications (including bug reports) are conducted in
public. The public nature of open source helps developers take pride
in their successes and think twice before releasing faulty code.

</OL>

<P>Furthermore, debugging is much more effective when split among many
people who have diverse knowledge.
<BR>
<BR>

<span class="InputHeader">Build and Test Management</span>

<P>Development activity on open source projects is constant and
concurrent among many developers. Sometimes the changes made by one
developer interfere with those made by another developer.

<P>Often the version control practices used in the open source
community resolve these conflicts, but sometimes they do not. Frequent
automated builds and tests of the software being developed are
powerful tools that help catch logical conflicts early.
<BR>
<BR>

<span class="InputHeader">Project Management</span> 

<P>Every project needs explicit goals, resources, and a schedule. The
open source community has addressed these issues in a uniquely
flexible way. Shared "to do" lists keep track of tasks that need to be
done. Personal "to do" lists keep developers on track. Milestone lists
set flexible deadlines for individual features based on feedback from
users and developers.
<BR>
<BR>

<span class="InputHeader">Knowledge Management</span>

<P>Knowledge is the valuable resource that sets experienced developers
apart from novice ones. Sharing knowledge effectively has been key to
the success of the open source community. Explicitly managing
knowledge can help reduce the learning curve for novices which reduces
the barriers to entry for potential contributors while automatically
keeping the load on the experts down to a minimum in terms of training
others.

</TD>
</TR>
</TABLE>
</BODY>
</HTML>
@


1.2
log
@added <title> tags to all files
@
text
@@


1.1
log
@moved core documentation into helm, fewer overrides need to be in instances now
@
text
@d1 7
d126 2
@


1.1.1.1
log
@Replacing the HEAD with the HELM_PEER_PORT_BRANCH.
@
text
@a0 7
<HTML>
<HEAD>

<TITLE>Open Source Best Practices</TITLE>

</HEAD>
<BODY>
a118 2
</BODY>
</HTML>
@


1.1.8.1
log
@porting changes from the head to the branch
@
text
@a0 7
<HTML>
<HEAD>

<TITLE>Open Source Best Practices</TITLE>

</HEAD>
<BODY>
a118 2
</BODY>
</HTML>
@


1.1.4.1
log
@adding the generic, default docs into this branch, bc they are in the head and nec for instantiations using stable branches
@
text
@@

