content/editorial/ec13July.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></p>
 13 July 2001
 <br><br>
 <h4>The OpenOffice.org Infrastructure Upgrade, Part II</h4>
 <p>OpenOffice.org will be migrating from its current platform, <a href="http://www.tigris.org" target="_blank">Tigris
   Classic</a>, to <a href="http://www.sourcecast.org/products/sourcecast/" target="_blank">SourceCast</a>,
   an updated version of Tigris. In a <a href="./ec29June.html" target="_blank">previous
   article</a>, I discussed some of the more obvious advantages the new platform
   offers the community. I'd like here to go over two other important features
   community members will be able to take advantage of: logging in and project
   and user groups.</p>
 <h4>Log In</h4>
 <p>Tigris Classic places a harmless cookie in a user's browser. This cookie generates
   a session id that is valid only for that session. Users are not identified,
   sessions are: Privacy is respected. SourceCast follows in a similar vein, in
   that it respects user privacy, as does <a href="http://www.sun.com" target="_blank">Sun
   Microsystems</a> (which sponsors OpenOffice.org) and <a href="http://www.collab.net" target="_blank">CollabNet</a>
   (which hosts OpenOffice.org). Only, because it has been designed to support
   project joining and thus log-ins, SourceCast uses a different technology: log-ins.
   Casual visitors who visit OpenOffice.org on SourceCast will be logged in as
   &quot;guest&quot; and given a randomly generated password good for that session.
   For casual visitors, that's it, and no other information will be asked for.
   In short, there will be no experiential difference between OpenOffice.org on
   SourceCast and OpenOffice.org on Tigris Classic, at least for the casual visitor.</p>
 <p>But for those who want to join projects (and propose them), and who want to
   contribute patches, etc., to OpenOffice.org? For these individuals, there is a difference.
   By registering and logging in, the contributor can join projects, can propose
   projects, and can work on the issues that concern a project. The reason for
   this? To encourage members to join projects and to provide project leads (named
   project owners in SourceCast) with some means by which to manage the work that
   must be done. And, as I mentioned last week, this and other features are optional.
   One need not join a project to participate in OpenOffice.org.</p>

 <p>Okay, but what is entailed in registration? That is, what sort of information
   is garnered? And what about privacy? Briefly, SourceCast gathers a username,
   password, and e-mail address. The advantages? In this way, for instance, registered
   users, who have joined projects and agreed to work on issues, can file and be
   assigned issues and contacted for work on those issues by IssueZilla, our bug
   and issue tracker. This represents a change: currently, anyone can file an issue;
   but people seldom seem to, and instead resort to sending email. With SourceCast,
   only registered users will be able to file issues (and be assigned issues).
   As a result of this change, the hope is that registered users will feel more
   involved in the community and consider OpenOffice.org a community for which
   the contributor is partly responsible. Gone will be the situation in which you
   can file an issue without the sense that someone else can assign you one, too.
   In this way, we move further away from a retail model, in which there are customers
   or clients who might complain about issues and there is an 'us' and 'them,'
   and closer to a true, Open Source model, in which everyone is involved.</p>
 <p>Registration enables project leads to invite registered users to their projects.
   The registered user can of course decline the offer, of course, as there the
   choice remains, naturally, with the developer. And, no doubt, some developers
   will be more popular for some than others: the meritocracy won't disappear.
   Actually, SourceCast will allow the development of a more nuanced meritocracy.
   For it articulates a sophisticated ensemble of roles and permissions that registered
   users can be granted. Tigris Classic has really only two categories: someone
   can either write or they can't, to the CVS tree. In SourceCast, a registered
   user can be a &quot;content developer,&quot; an &quot;observer&quot; or any
   other role that the project lead feels addresses what must be done. </p>
 <p>Indeed, by registering, we are making it much easier for a worthy project to
   succeed, for the project owner will be able to invite talented contributors
   with a spectrum of talents with minimal fuss. </p>

 <h4><br>
   Groups: Projects and Users</h4>
 <p>SourceCast allows for the grouping of registered users and projects. Projects
   can be grouped together according to any reasonable criteria, such as technology.
   What is more, any one project can belong to more than one group. And users can
   be involved in several user groups. Thus, for instance, the Porting project
   might become affiliated with a GUI project, and with the XML project. </p>
 <p>In effect, a project group can be considered a sort of inclusive project, with
   much of what that implies, minus the presence of a project lead. The grouping
   feature is more than an administrative boon. It also makes it easier for users
   to keep apprised of what is going on in those projects with which she is
   involved, and simplifies the process by which a user's roles and permissions
   can be managed.</p>
 <p>There are, to be sure, other features which I have not fully discussed. Such
   as searchable mail archives (finally); or the possibility of per-project news.
   As the migration process continues, I will be posting more tips on SourceCast.
 </p>
 <p>&nbsp;</p>
 <p><a href="index.html">Previous articles</a></p>

 </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></p>
	13 July 2001
	<br><br>
	<h4>The OpenOffice.org Infrastructure Upgrade, Part II</h4>
	<p>OpenOffice.org will be migrating from its current platform, <a href="http://www.tigris.org" target="_blank">Tigris
	Classic</a>, to <a href="http://www.sourcecast.org/products/sourcecast/" target="_blank">SourceCast</a>,
	an updated version of Tigris. In a <a href="./ec29June.html" target="_blank">previous
	article</a>, I discussed some of the more obvious advantages the new platform
	offers the community. I'd like here to go over two other important features
	community members will be able to take advantage of: logging in and project
	and user groups.</p>
	<h4>Log In</h4>
	<p>Tigris Classic places a harmless cookie in a user's browser. This cookie generates
	a session id that is valid only for that session. Users are not identified,
	sessions are: Privacy is respected. SourceCast follows in a similar vein, in
	that it respects user privacy, as does <a href="http://www.sun.com" target="_blank">Sun
	Microsystems</a> (which sponsors OpenOffice.org) and <a href="http://www.collab.net" target="_blank">CollabNet</a>
	(which hosts OpenOffice.org). Only, because it has been designed to support
	project joining and thus log-ins, SourceCast uses a different technology: log-ins.
	Casual visitors who visit OpenOffice.org on SourceCast will be logged in as
	"guest" and given a randomly generated password good for that session.
	For casual visitors, that's it, and no other information will be asked for.
	In short, there will be no experiential difference between OpenOffice.org on
	SourceCast and OpenOffice.org on Tigris Classic, at least for the casual visitor.</p>
	<p>But for those who want to join projects (and propose them), and who want to
	contribute patches, etc., to OpenOffice.org? For these individuals, there is a difference.
	By registering and logging in, the contributor can join projects, can propose
	projects, and can work on the issues that concern a project. The reason for
	this? To encourage members to join projects and to provide project leads (named
	project owners in SourceCast) with some means by which to manage the work that
	must be done. And, as I mentioned last week, this and other features are optional.
	One need not join a project to participate in OpenOffice.org.</p>

	<p>Okay, but what is entailed in registration? That is, what sort of information
	is garnered? And what about privacy? Briefly, SourceCast gathers a username,
	password, and e-mail address. The advantages? In this way, for instance, registered
	users, who have joined projects and agreed to work on issues, can file and be
	assigned issues and contacted for work on those issues by IssueZilla, our bug
	and issue tracker. This represents a change: currently, anyone can file an issue;
	but people seldom seem to, and instead resort to sending email. With SourceCast,
	only registered users will be able to file issues (and be assigned issues).
	As a result of this change, the hope is that registered users will feel more
	involved in the community and consider OpenOffice.org a community for which
	the contributor is partly responsible. Gone will be the situation in which you
	can file an issue without the sense that someone else can assign you one, too.
	In this way, we move further away from a retail model, in which there are customers
	or clients who might complain about issues and there is an 'us' and 'them,'
	and closer to a true, Open Source model, in which everyone is involved.</p>
	<p>Registration enables project leads to invite registered users to their projects.
	The registered user can of course decline the offer, of course, as there the
	choice remains, naturally, with the developer. And, no doubt, some developers
	will be more popular for some than others: the meritocracy won't disappear.
	Actually, SourceCast will allow the development of a more nuanced meritocracy.
	For it articulates a sophisticated ensemble of roles and permissions that registered
	users can be granted. Tigris Classic has really only two categories: someone
	can either write or they can't, to the CVS tree. In SourceCast, a registered
	user can be a "content developer," an "observer" or any
	other role that the project lead feels addresses what must be done. </p>
	<p>Indeed, by registering, we are making it much easier for a worthy project to
	succeed, for the project owner will be able to invite talented contributors
	with a spectrum of talents with minimal fuss. </p>

	<h4><br>
	Groups: Projects and Users</h4>
	<p>SourceCast allows for the grouping of registered users and projects. Projects
	can be grouped together according to any reasonable criteria, such as technology.
	What is more, any one project can belong to more than one group. And users can
	be involved in several user groups. Thus, for instance, the Porting project
	might become affiliated with a GUI project, and with the XML project. </p>
	<p>In effect, a project group can be considered a sort of inclusive project, with
	much of what that implies, minus the presence of a project lead. The grouping
	feature is more than an administrative boon. It also makes it easier for users
	to keep apprised of what is going on in those projects with which she is
	involved, and simplifies the process by which a user's roles and permissions
	can be managed.</p>
	<p>There are, to be sure, other features which I have not fully discussed. Such
	as searchable mail archives (finally); or the possibility of per-project news.
	As the migration process continues, I will be posting more tips on SourceCast.
	</p>
	<p> </p>
	<p><a href="index.html">Previous articles</a></p>

	</body>
	</html>