head	1.3;
access;
symbols
	TIGRIS_1_1_0RC2:1.3.2.1
	TIGRIS_1_1_0RC1:1.3.2.1
	TIGRIS_1_1:1.3.2.1.0.2
	TIGRIS_1_0_8:1.3.2.1
	TIGRIS_1_0_8RC3:1.3.2.1
	TIGRIS_1_0_8RC2:1.3.2.1
	TIGRIS_1_0:1.3.0.2;
locks; strict;
comment	@# @;


1.3
date	2001.06.21.07.07.40;	author jefflove;	state Exp;
branches
	1.3.2.1;
next	1.2;

1.2
date	2001.06.11.03.14.33;	author jefflove;	state Exp;
branches;
next	1.1;

1.1
date	2001.05.17.22.35.44;	author lori;	state Exp;
branches;
next	;

1.3.2.1
date	2001.07.13.00.05.29;	author tberry;	state Exp;
branches;
next	;


desc
@@


1.3
log
@html usage revision
@
text
@  <div class="docs" id="bestpractices">
<h2>Key Open Source "Best Practices" supported on this site</h2> 

  <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.</p>
  <h3>Technical Communication</h3> 

  <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.i</p>

  <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.</p>
  <h3>Version Control, Document Management, and Distribution</h3> 

  <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>

  <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.</p>
  <h3>Quality Assurance</h3> 

  <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>

  <p>Open source software is high quality for three main reasons:</p>

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

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

   <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.</li>
  </ol>

  <p>Furthermore, debugging is much more effective when split among many people who have diverse knowledge.</p>
  <h3>Build and Test Management</h3> 

  <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>

  <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.</p>
  <h3>Project Management</h3> 

  <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.</p>
  <h3>Knowledge Management</h3> 

  <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.</p>
 </div>



@


1.3.2.1
log
@adding this file to the branch cause it's missing.  Also to fix broken link in the FAQ
Issue number:
Obtained from:
Submitted by:
Reviewed by:
@
text
@@


1.2
log
@extensive markup rework - first pass toward house xhtmlification
@
text
@a0 8
<!DOCTYPE html PUBLIC "-//CollabNet//DTD XHTML 1.0 Transitional//EN"
"http://collabnet.com/dtds/collabnet_transitional_10.dtd">
<html>
 <head>
  <title>Open Source Best Practices</title>
 </head>

 <body>
d42 1
a42 2
</body>
</html>
@


1.1
log
@Formerly known as 'DomainDocs_bestpractices.html', but the DomainDocs*.html nomenclature was dropped in the help redesign for the 1.0.0 release. Somehow the newer doc got dropped, or perhaps was never properly added.
@
text
@d1 2
d4 3
a6 1
<head>
d8 3
a10 1
<title>Open Source Best Practices</title>
d12 2
a13 95
</head>
<body>
    <span class="Header">Key Open Source "Best Practices" supported on this site</span>  
 
    <span class="PlainText">

<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.
</p>

<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.i</p>

<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.</p>  

<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>

<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.</p>

<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>

<p>Open source software is high quality for three main reasons:</p>
<ol>

<li>Developers are self-selected by their interest and knowledge of
the application domain.</li>
<p></p>
<li>Requirements are tacitly understood by developers who are
themselves users of the software.</li>
<p></p>
<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.</li>

</ol>

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

<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>

<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.</p>

<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.</p>

<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.</p>
d15 35
a49 1
</span>
d52 1
@

