content/editorial/ec29June.html - openoffice-org - Git at Google

 <html><head>
 <meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
 </head>
 <body>

 <h2> Community
   Articles: Opinions, Interviews, Analyses</h2>
 <p><a href="//lspintro.html" target="_blank">-Louis Su&aacute;rez-Potts</a></p>
 <p>2 July 2001</p>
 <p>&nbsp; </p>
 <h4>The OpenOffice.org Infrastructure Upgrade</h4>

 <p>The OpenOffice.org infrastructure is going to be upgraded. In less than two
   weeks' time, on the afternoon of July 13, 2001, OpenOffice.org will move from
   its current infrastructure (<a href="http://www.tigris.org" target="_blank">Tigris</a>
   Classic), to a more modern and sophisticated version, <a href="http://www.sourcecast.org/products/sourcecast/" target="_blank">SourceCast</a>.
   During this period of transition, the site, including the <a href="http://www.cvshome.org/" target="_blank">CVS</a>
   repository, will be down for what may end up being several hours. And when it's
   back up, it will be decidedly improved.</p>

 <p>What does the upgrade bring? To begin with, SourceCast gives the community
   the tools by which they can more directly participate in building OpenOffice.org
   and its member projects. Second, it simplifies the task of managing mailing
   lists and projects. </p>

 <p>But first: The site will look pretty much the same. Changes will mostly be  subtle. But many will find additions that will prove very welcome indeed; these need to be highlighted. For instance, SourceCast
   comes replete with logically laid-out documentation on how to use IssueZilla,
   CVS, and just about everything else pertaining to the site infrastructure. (As
   opposed to the site <i>content,</i> or the OpenOffice.org code.) This means that
   users (at least those who read the Help) will at last be able to find context-sensitive
   answers to many questions. </p>

 <p>I would like in this article to go over some of the differences
   in SourceCast and to suggest ways in which community members will be able to grasp
   this opportunity to--perhaps!--accelerate the development of the project. For,
   as has become clear in the last several weeks, the community has reached point
   where members are forming projects to satisfy longstanding needs. This discussion
   will be the first of at least two; it will focus on joining and proposing projects.
   Subsequent announcements will deal with other aspects of the upgrade.</p>

 <br>
 <h4>Joining projects</h4>
 <p>Join a project? With our present model, that phrase almost makes no sense.
   One can certainly <i>subscribe</i> to a project's mailing list, and, to
   be sure, a select few can even become committers to a project's CVS tree.
   But join? </p>

 <p>Yes, join. SourceCast formalizes a process that in our current model of Tigris
   is by no means self-evident. Thus, the group that is working on, say, the Documentation
   Project in the Whiteboard, may work together, and well, but there is no
   clear and efficient mechanism for them to distribute work among themselves;
   or if there is, it is home-grown and not necessarily extensible to other projects.
   This situation holds true for other, larger projects, such as Porting, where
   the problem is magnified by the extent and complexity of the work. </p>

 <p>So instead of a system that relies upon the unformalized understanding of a
   project's contributors and mailing-list subscribers, SourceCast allows
   for a clarification of responsibility. Members can be more coherently thought
   of as "members," with clearly understood responsibilities (determined
   by the leader and group). Again, this system has more or less worked fine so
   far. But, as I've noted before, we are growing, and fast. </p>

 <p>SourceCast <i>does not</i>, by any means, require that community members (loosely
   defined) join a project, in order to work on that project. The status quo can
   continue, and we need not change our way of operating. But let's say that a
   project lead, supported by that project's contributors, does take advantage
   of the SourceCast functionality, and chooses to use the joining feature. Members
   will not only possess a better understanding of their responsibilities and of
   the tasks they have agreed to undertake, but they will also be able, if the
   project lead is willing, to have a more pronounced role in determining a project.
   I'll go over these points in greater depth later, but, in a nutshell, the point
   of explicit membership is not just to provide a mechanism for the allocation
   of work but to grant to members the incentive of clearly established responsibility.</p>
 <br>
 <h4>Proposing projects</h4>

 <p>Currently, any regular visitor of the OpenOffice.org site can propose a new
   project. Most regular visitors to OpenOffice.org probably don't know this, but,
   it's so. It's also one of the better features not only of OpenOffice.org but
   of any Open Source project: If you want something done, you can join or create
   a project to get that thing done. SourceCast takes this characteristic of an
   Open Source project and foregrounds it, making it a simple exercise for members
   to propose new projects. The (hoped-for) result: More things are accomplished
   by more community members working together. </p>

 <p>Implicitly, the emphasis for now is on &quot;proposing projects.&quot; And
   why just propose and not actually create? Because it would be foolish to allow
   for the empty proliferation of unneeded and unheeded projects that might end
   up proving more distracting than useful. So, every new proposal will have to
   be approved before it is accepted. As it happens, this is the way we've been
   working so far. That said, I fully expect that the simplicity of the new model
   will eventually lead to some modifications in the process by which proposed
   projects are approved. </p>
 <br>
 <h4>Conclusion</h4>

 <p>To say that SourceCast has many other features that the community will benefit
   from is to understate the case. For instance, as I will describe in subsequent
   articles, with SourceCast we can organize and group projects and members in
   ways that counteract the fragmentation any large Open Source project is subject
   to.</p>
 <p>Next week, I will further focus on what is entailed by joining a project.</p>
 <br><br><a href="./editors.html">Previous Articles
   </a>
 </body>
 </html>
	<html><head>
	<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
	</head>
	<body>

	<h2> Community
	Articles: Opinions, Interviews, Analyses</h2>
	<p><a href="//lspintro.html" target="_blank">-Louis Suárez-Potts</a></p>
	<p>2 July 2001</p>
	<p>  </p>
	<h4>The OpenOffice.org Infrastructure Upgrade</h4>

	<p>The OpenOffice.org infrastructure is going to be upgraded. In less than two
	weeks' time, on the afternoon of July 13, 2001, OpenOffice.org will move from
	its current infrastructure (<a href="http://www.tigris.org" target="_blank">Tigris</a>
	Classic), to a more modern and sophisticated version, <a href="http://www.sourcecast.org/products/sourcecast/" target="_blank">SourceCast</a>.
	During this period of transition, the site, including the <a href="http://www.cvshome.org/" target="_blank">CVS</a>
	repository, will be down for what may end up being several hours. And when it's
	back up, it will be decidedly improved.</p>

	<p>What does the upgrade bring? To begin with, SourceCast gives the community
	the tools by which they can more directly participate in building OpenOffice.org
	and its member projects. Second, it simplifies the task of managing mailing
	lists and projects. </p>

	<p>But first: The site will look pretty much the same. Changes will mostly be subtle. But many will find additions that will prove very welcome indeed; these need to be highlighted. For instance, SourceCast
	comes replete with logically laid-out documentation on how to use IssueZilla,
	CVS, and just about everything else pertaining to the site infrastructure. (As
	opposed to the site <i>content,</i> or the OpenOffice.org code.) This means that
	users (at least those who read the Help) will at last be able to find context-sensitive
	answers to many questions. </p>

	<p>I would like in this article to go over some of the differences
	in SourceCast and to suggest ways in which community members will be able to grasp
	this opportunity to--perhaps!--accelerate the development of the project. For,
	as has become clear in the last several weeks, the community has reached point
	where members are forming projects to satisfy longstanding needs. This discussion
	will be the first of at least two; it will focus on joining and proposing projects.
	Subsequent announcements will deal with other aspects of the upgrade.</p>

	<br>
	<h4>Joining projects</h4>
	<p>Join a project? With our present model, that phrase almost makes no sense.
	One can certainly <i>subscribe</i> to a project's mailing list, and, to
	be sure, a select few can even become committers to a project's CVS tree.
	But join? </p>

	<p>Yes, join. SourceCast formalizes a process that in our current model of Tigris
	is by no means self-evident. Thus, the group that is working on, say, the Documentation
	Project in the Whiteboard, may work together, and well, but there is no
	clear and efficient mechanism for them to distribute work among themselves;
	or if there is, it is home-grown and not necessarily extensible to other projects.
	This situation holds true for other, larger projects, such as Porting, where
	the problem is magnified by the extent and complexity of the work. </p>

	<p>So instead of a system that relies upon the unformalized understanding of a
	project's contributors and mailing-list subscribers, SourceCast allows
	for a clarification of responsibility. Members can be more coherently thought
	of as "members," with clearly understood responsibilities (determined
	by the leader and group). Again, this system has more or less worked fine so
	far. But, as I've noted before, we are growing, and fast. </p>

	<p>SourceCast <i>does not</i>, by any means, require that community members (loosely
	defined) join a project, in order to work on that project. The status quo can
	continue, and we need not change our way of operating. But let's say that a
	project lead, supported by that project's contributors, does take advantage
	of the SourceCast functionality, and chooses to use the joining feature. Members
	will not only possess a better understanding of their responsibilities and of
	the tasks they have agreed to undertake, but they will also be able, if the
	project lead is willing, to have a more pronounced role in determining a project.
	I'll go over these points in greater depth later, but, in a nutshell, the point
	of explicit membership is not just to provide a mechanism for the allocation
	of work but to grant to members the incentive of clearly established responsibility.</p>
	<br>
	<h4>Proposing projects</h4>

	<p>Currently, any regular visitor of the OpenOffice.org site can propose a new
	project. Most regular visitors to OpenOffice.org probably don't know this, but,
	it's so. It's also one of the better features not only of OpenOffice.org but
	of any Open Source project: If you want something done, you can join or create
	a project to get that thing done. SourceCast takes this characteristic of an
	Open Source project and foregrounds it, making it a simple exercise for members
	to propose new projects. The (hoped-for) result: More things are accomplished
	by more community members working together. </p>

	<p>Implicitly, the emphasis for now is on "proposing projects." And
	why just propose and not actually create? Because it would be foolish to allow
	for the empty proliferation of unneeded and unheeded projects that might end
	up proving more distracting than useful. So, every new proposal will have to
	be approved before it is accepted. As it happens, this is the way we've been
	working so far. That said, I fully expect that the simplicity of the new model
	will eventually lead to some modifications in the process by which proposed
	projects are approved. </p>
	<br>
	<h4>Conclusion</h4>

	<p>To say that SourceCast has many other features that the community will benefit
	from is to understate the case. For instance, as I will describe in subsequent
	articles, with SourceCast we can organize and group projects and members in
	ways that counteract the fragmentation any large Open Source project is subject
	to.</p>
	<p>Next week, I will further focus on what is entailed by joining a project.</p>
	<br><br><a href="./editors.html">Previous Articles
	</a>
	</body>
	</html>