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

<h2><font face="Arial, Helvetica, sans-serif" color="cc6600">Process guide</font></h2>
<br>
<P> Louis Su&aacute;rez-Potts<br>
<a href="mailto:louis@openoffice.org">louis@openoffice.org </a></p>
<h4>Contents<a name="top"></a> <br>
</h4>
<dl>
<dt><a href="#preface">Preface</a></dt>
<dt> <a href="#I">I. Communication plan: what and when</a></dt>
<dd> <a href="#Ia">a. Project leads</a></dd>
<dd> <a href="#Ib">b. Community</a></dd>
<dt> <a href="#II">II. Inventory: files moved and files added</a></dt>
<dd> <a href="#IIa">a. Files migrated</a></dd>
<dd> <a href="#IIb">b. Files added (help files, etc.)</a></dd>
  <dt> <a href="#III">III. What has changed</a></dt>
<dd> <a href="#IIIa">a. Structure</a></dd>
<dd> <a href="#IIIb">b. Little has changed in content</a></dd>
<dd> <a href="#IIIc">c. Much has changed (or can change) in spirit</a></dd>
<dd> <a href="#IIId">d. Permissions and project roles</a></dd>
<dt> <a href="#IV">IV. Creating new projects: who can do it?</a></dt>
<dd> <a href="#IVa">a. Registered users</a></dd>
<dd> <a href="#IVb">b. Project leads</a></dd>
<dd> <a href="#IVc">c. How is it done?</a></dd>
<dt> <a href="#V">V. Using project features: salient points</a></dt>
<dd> <a href="#Va">a. Documents</a></dd>
<dd> <a href="#Vb">b. News</a></dd>
<dd> <a href="#Vc">c. Issues</a></dd>
<dd> <a href="#Vd">d. Source code</a></dd>
<dt> <a href="#VI">VI. Hosted tools</a></dt>
<dt> <a href="#VIII">VII. Conclusion</a></dt>
</dl>
<br>
<h4>Preface<a name="preface"></a></h4>
<ol start=1 type=A>
  <li>This is a primer: It is meant to provide insight, not to answer all questions. 
    Please look it over. Its main virtue: it links to the help documents that 
    answer specific questions. </li>
  <li>OpenOffice.org is currently being migrated over to SourceCast from Tigris. 
    Both SourceCast and Tigris use "WebMacro" technology, which dynamically 
    deploys HTML pages as required. Framing each page is a static structure; this 
    where the navbars, headers, and footers live. </li>
  <li>The similarities between Tigris and SourceCast are such that most users 
    would probably not notice any real difference between the two platforms. </li>
  <li>However, there are clearly differences, especially in functionality, and 
    they are important. For instance, OpenOffice.org under SourceCast relies more 
    on serving up pages according to a user's (visitor's) permissions; 
    it is more dynamically responsive and more configurable. Mailing lists, as 
    well, are a little different: they are more easily managed, something users 
    and project leads will surely appreciate. </li>
  <li>This document will go over the primary differences between Tigris OpenOffice.org 
    (t-OpenOffice.org) and SourceCast OpenOffice.org (sc-OpenOffice.org), focusing 
    on those areas that are most likely to be sources of confusion. I anticipate 
    that this document is but a start. There will surely be issues that are not 
    fully covered here and that emerge only with user experience. </li>
  <li>But first: Terms. </li>
  <ol start=1 type=a>
    <li>In t-OpenOffice.org we use the term Project Lead and Project Owner interchangeably. 
      Sc-OpenOffice.org uses "project owner." In t-OpenOffice.org, 
      Sun project leads have domain-wide read/write privileges. In effect, a t-OpenOffice.org 
      project lead is a domain admin. In sc-OpenOffice.org, a project owner does 
      not axiomatically have such privileges. Rather, sc-OpenOffice.org distinguishes 
      between project owner, who has total privileges over his or her project, 
      and a domain admin, who has privileges over the entire ensemble of projects.</li>
  </ol>
  <li>And second: The current version of OpenOffice.org on SourceCast is not necessarily 
    the final one. Think of it as a proving ground. Indeed, one of its functions 
    is to provide a training ground for project leads and administrators, so that 
    we can all learn for ourselves how SourceCast works. That means that:</li>
  <ol start=1 type=a>
    <li>Comments, desires, and criticisms should be brought to CollabNet's 
      attention as soon as possible. I, Louis (<a
      href="mailto:louis@collabnet">louis@collabnet</a>), have been appointed 
      the contact person for these sorts of questions. To the best of my ability, 
      I will address questions regarding sc-OpenOffice.org use; those questions 
      I cannot competently answer, I will defer to Jeff Love, who is leading the 
      migration. </li>
  </ol>
</ol>
<p><a href="#top">Back to top</a></p>
<h3><a name="I"></a> Communication plan: what and when</h3>
<blockquote> 
  <p> a<a name="Ia"></a>. <u>Project leads</u>. OpenOffice.org has now two categories 
    of project leads: Sun and non-Sun employees. This guide addresses the concerns 
    of both categories of project leads; no distinction is made. In truth, this 
    guide provides but a start; more will be added as the week progresses and 
    new questions surface. As stated above, please read over this guide, and use 
    the Help documentation in sc-OpenOffice.org. Questions should be sent to me, 
    and not to the discuss list. Why? Because we haven't notified the community 
    yet. That will happen next week.</p>
  <p> b<a name="Ib"></a>. <u>Community:</u> Goolie and Louis will work on a message 
    for the community, to be sent out 29 June. For the casual user OpenOffice.org 
    on SourceCast will make little difference. However, SourceCast does use a 
    registration model, and even the most casual user is automatically, if invisibly, 
    logged in. What is more, depending on the permissions granted a user, she 
    will see different aspects of the site. This will be explained to the community 
    at large, and the advantages of registering will be explained. All this will 
    be detailed in the message to be sent out 29 June. We expect that the message 
    will be the start of a continuing explicatory phase.</p>
  <blockquote>
    <p> i. There might be some resistance within the OpenOffice.org community, 
      for the user will, for the first time, be given the option to register, 
      which implies both good and bad things. The messaging will have to deal 
      with that. I do not, actually, anticipate too many objections, for explicit 
      registration will bring with it considerable advantages (project leads willing). 
      These will include the ability to join projects and act in a manner that 
      is more engaged with the work at hand. But it may also create a tiered structure, 
      whereby visitors who are not members see one version of the site, and registered 
      members who are part of projects see other parts. The simpler structure 
      of t-OpenOffice.org gives the appearance of a horizontality that actually 
      still exists within sc-OpenOffice.org, although it is more nuanced. But 
      the appearance of that horizontality shifts.</p>
    <p> ii. To overcome some of the objections, the community will have to be 
      apprised of the extensive and clear site documentation (the Help and Site 
      FAQs) that explain sc-OpenOffice.org's functionality. Concepts such as IssueZilla, 
      CVS, SSH, and so on, are clearly explicated, with examples, in the Hosted 
      Tools section of the Help. (Note: the SSH documentation will be up-to-date 
      by the time the site goes live.)</p>
    <p> iii. Mailing List. As well, the community will be informed of the differences. 
      Subscribing/unsubscribing will be the same, indeed, easier. A significant 
      plus, however, will be the much-longed-for introduction of searchable archives. 
      (Note: It is anticipated that by the time the changeover is complete, in 
      the middle of July, OpenOffice.org will be using a newsgroup server [NNTP]. 
      For the sake of simplicity and clarity, this guide won't touch on that.)</p>
  </blockquote>
</blockquote>
<p><a href="#top">Back to top</a></p>
<h4> <br>
  II<a name="II"></a>. Inventory: files moved and files added</h4>
<blockquote> 
  <p> a<a name="IIa"></a>. <u>Files Migrated. </u>All the OpenOffice.org-specific 
    files that make up Tigris OpenOffice.org have been successfully moved to SourceCast 
    OpenOffice.org. The files that will be migrated at the last minute, in the 
    week of July 13, include those few files that have not already been migrated, 
    as well as files updated since the initial migration. Until then, we should 
    continue to proceed normally on t-OpenOffice.org; and we should also be testing 
    sc-OpenOffice.org.</p>
  <p> b<a name="IIb"></a>. <u>Files Added.</u> Besides the test and bogus files, 
    the most obvious instance of added files are those that come packaged with 
    SourceCast, such as the SourceCast Help files and Site FAQs.</p>
  <blockquote>
    <p> i. Help Files, including Site FAQ. The files included here provide a fairly 
      thorough primer of SourceCast and how to use it. Actually, as will become 
      apparent, this guide will use many of the files to explain how to set permissions, 
      how to load files, how to edit projects. </p>
  </blockquote>
</blockquote><br>
<p><a href="#top">Back to top</a> </p>
<h4> III<a name="III"></a>. What has changed</h4>
<blockquote> 
  <p> a<a name="IIIa"></a>. <u>Structure</u>. Both sc-OpenOffice.org and t-OpenOffice.org 
    manipulate CVS files. Hence, there can only be so much difference between 
    the two platforms. The biggest change is that sc-OpenOffice.org doesn't automatically 
    support the idea of a sub-project in the same way that t-OpenOffice.org does. 
    Rather, sc-OpenOffice.org supports the more sophisticated concept of a "resource." 
    But, in both cases, what is being controlled is access to a CVS module. A 
    resource can be thought of as a file or group of files over to which a certain 
    role pertains; and precise permissions can be associated with this role. A 
    project owner can request that a new resource be added to his project and 
    that a new role be associated with this resource. Once that role is available 
    to the project owner (something the domain admin must do), the project owner 
    can then add any number of project members to that project with that role, 
    and he or they will <i>only</i> have access to that resource. Why? Their project 
    role has limited their access to other resources. And, yes, a member can have 
    more than one role.</p>
  <blockquote> 
    <p> i. Example. Mary wants to create a new sub-project, "talk" within the 
      "VoiceRecognition" project. Solution: the project owner submits a request 
      to the domain admin (who can add new resources to projects) that a new resource 
      corresponding to "voicerecognition/talk/" be added. The domain admin must 
      also create a new role "talkdeveloper," say, which directly corresponds 
      to the new resource just created. Fred, the owner of "VoiceRecognition" 
      can then add Mary to the project with the new role, &quot;talkdeveloper.&quot; 
      If she only has that new role (the &quot;talkdeveloper&quot; role), she 
      will only have access to that "sub-project," or more accurately, resource.</p>
    <p> ii. I have no doubt that there will be questions related to this modification. 
      Those with domain admin privileges can work through the process by logging 
      in, and from their Start Page, click on &quot;Adminster Roles&quot; in the 
      top, uner &quot;Admin Options.&quot; From there, go to the &quot;Roles &amp; 
      Resources&quot; link on the SourceCast navbar. And add a new resource. Experiment 
      with the provisions of the process.</p>
    <p>iii. The advantage of this method is that it allows for greater precision 
      and ultimately security. The drawback is that it adds a step in which the 
      project owner must petition (send a request to) the domain admin to implement 
      the desired change. However, as OpenOffice.org is growing, and including 
      more and more non-Sun project owners, this added step is all the clearer 
      an advantage.</p>
  </blockquote>
  <p> b<a name="IIIb"></a>. <u>Categories</u>. In the current sc-OpenOffice.org, 
    projects are listed by generic "category." This will change, as we do not 
    really need to use category at all. Rather, we can create one category: OpenOffice.org, 
    and transplant (with some changes to prevent an immune reaction) the current 
    HTML page describing the projects, leaders, and purposes. </p>
  <p> c<a name="IIIc"></a>. <u>Little has changed in content.</u> This implementation 
    of SourceCast is similar to the current OpenOffice.org implementation on Tigris. 
    But there are changes, both for project owners, admins, and for registered, 
    regular users, though the changes a typical user will encounter are fairly 
    minor. Among the things that have changed, the most obvious is:</p>
  <blockquote> 
    <p> i. The Login. This login in feature will automatically login <b>any</b> 
      nonregistered user as "anonymous." Registered users must log in manually 
      each new session. The advantages of the login feature are many, including 
      the ability of registered users to go automatically to their "start" page 
      upon logging in. This page lists those projects they have joined or created, 
      as well as other available projects, by category. Projects in which the 
      user does not have a direct role are not presented by default. For instance, 
      sc-OpenOffice.org creates the new concept of groups for projects and members 
      (see: <a
href="//project/www/docs/DomAdminUserGroups.html">//project/www/docs/DomAdminUserGroups.html</a>). 
    </p>
    <p> ii. And, from an administrative perspective, the login feature allows 
      some control of information and visitor traffic, if wanted. </p>
    <p> iii. Logging in. Project leads&#8212;admins&#8212;must login using their 
      current t-OpenOffice.org account username and password to appreciate (to 
      use) SourceCast's sophisticated admin features. Take, for example, the Help. 
      When we were constructing the help system, the idea was to accord Help files 
      with the user. A project leader will see a different Help set of files than 
      a nonregistered user. Thus, to get the most out of the Help (including the 
      links I am citing here), project leaders must log on. And I encourage you 
      to use the Help files.</p>
    <p> iv. Use the Help. This is especially true right now, while this site is 
      under construction. For instance, all of t-OpenOffice.org's many projects 
      are not visible unless one enters as a domain admin. This will change, to 
      be sure.</p>
  </blockquote>
  <p> d<a name="IIId"></a>. <u>Much has changed (or can change) in spirit.</u> 
    The great advantage of sc-OpenOffice.org is that it encourages a more engaged 
    role on the part both of the visitor (who can now more easily browse through 
    a project and its files) and of the current project owners. </p>
  <blockquote> 
    <p> i. Users, for instance, can now more easily (with the merest click of 
      a button) upload documents to the project site, project lead permitting. 
      And users can now "join" a project, a concept more or less impossible to 
      realize with t-OpenOffice.org, where one might join a most a mailing list. 
      This means that the micro-community making up a project will interact more 
      with the website element, as opposed to primarily living in the mailing 
      list space.</p>
  </blockquote>
  <p> e<a name="IIIe"></a>. <u>Permissions and project roles.</u> Perhaps the 
    most important change has to do with the advent of a sophisticated permissions 
    system which allows the project leader the ability to more easily grant specific 
    roles to developers who have joined his project. With t-OpenOffice.org, there 
    were rather few permissions at play: one could read or write or read and write 
    any particular module; these corresponded to the CVS modules making up the 
    project and determined the role of the individual. SourceCast folds in a level 
    of useful complexity that project leaders can take advantage of. For instance, 
    as I discussed above, in "Structure," a project owner can modify the permissions 
    of a developer to grant him or her access to particular files; or can create 
    new roles with a mix of permissions per file. I anticipate that this, one 
    of the more involved areas of the process, will generate some confusion. So:</p>
  <blockquote>
    <p> i. For information on roles and permissions, please see the general category 
      of help for project owner administration: <a
href="//project/www/docs/ProjectOwnerAdmin.html">//project/www/docs/ProjectOwnerAdmin.html</a>, 
      and the more specific help on permissions: <a
href="//project/www/docs/DomAdminRoles.html">//project/www/docs/DomAdminRoles.html</a>. 
      A good description of project roles: <a
href="//project/www/docs/ProjectRoles.html">//project/www/docs/ProjectRoles.html</a> 
    </p>
    <p> ii. However, the best way to understand the kinds of roles and permissions 
      over which a project leader has access is to create a practice project and 
      adjust the roles and privileges of willing subjects. For the most part, 
      this is routine; but you can grant the user a role that elevates her beyond 
      the casual visitor. You can even create new roles (if not permissions) that 
      will allow your project to grow smoothly. As well, members of the project 
      may request new roles of the project lead or leads.</p>
    <p> iii. In fact, you can delegate much of the responsibility of running the 
      project to a willing user. Yes, t-OpenOffice.org effectually offers the 
      same advantage; these are, after all, predicated on CVS modules. But sc-OpenOffice.org 
      allows greater flexibility in managing users and work on a project and in 
      providing valuable incentive to developers interested in joining a project. 
      For information on how to manage project members, please see: <a
href="http://look.openoffice.org/project/www/docs/ProjectOwnerMembers.html">http://look.openoffice.org/project/www/docs/ProjectOwnerMembers.html</a> 
    </p>
    <p> iv. Or, you can simply leave the permissions in a state that resembles 
      the current condition. That is, users will only be qualified as registered 
      users (if that) and will have few privileges. They will still be able to 
      view projects, and their associated files, but they will not have the full 
      privileges of a registered user, let alone a more trusted user. But: there 
      is no special need to alter the na&iuml;ve state of a developer. </p>
    <p> v. Getting used to the increased sophistication of sc-OpenOffice.org permissions 
      will doubtless take some getting used to, as it may not be apparent to project 
      leads why they should change the status quo. But: if granting more rights 
      to registered users results in growing the project and developing the code 
      faster&#8230;.</p>
  </blockquote>
</blockquote>
<br>
<p><a href="#top">Back to top</a> </p>
<h4> IV<a name="IV"></a>. Creating new projects. who can do it</h4>
<blockquote> 
  <p> a<a name="IVa"></a>. <u>Registered users.</u> Any registered user can propose 
    a new project. Will it be accepted? That depends on the domain admin, who 
    must decide on the project. And who is the domain admin? It can be a person, 
    or a group, such as is the present case, with t-OpenOffice.org. </p>
  <p> b<a name="IVb"></a>. <u>Project leads.</u> Currently, project leads can 
    create new projects only after the proposal has been approved by other project 
    leads. The same can obtain with sc-OpenOffice.org. </p>
  <p> c<a name="IVc"></a>. <u>How is it done?</u> <i>Very </i>easily. Or at least 
    the proposal simple enough to make. For information on the procedure, please 
    see: <a href="//">//</a> 
    . I recommend that everyone go through the process of creating a project. 
    In creating a project, one can, initially (it can be changed later), specify 
    the index page content (or deploy one of your own), assign roles, invite members, 
    and set up mailing lists and news pages. For these reasons it is very important 
    that project leads be familiar with the process. </p>
</blockquote>
<p><a href="#top"><br>
  Back to top</a> </p>
<h4> V<a name="V"></a>. Using project features: salient points</h4>
<blockquote> 
  <p> a<a name="Va"></a>. <u>Documents.</u> Currently, on t-OpenOffice.org, files 
    (documents, etc.) are committed to a project's modules by, usually, the project 
    leader. This power structure can continue into sc-OpenOffice.org., and the 
    project lead can continue to be the sole committer of documents. Should the 
    project lead wish to change the power structure, however, and allow others 
    who have decided to join the project to contribute documents, text, or news 
    items, this can easily be done by changing the permissions of the registered 
    users to allow it. See <a
href="http://look.openoffice.org/project/www/docs/ProjectOwnerDocuments.html">http://look.openoffice.org/project/www/docs/ProjectOwnerDocuments.html</a> 
    for a more detailed explanation.</p>
  <p> b<a name="Vb"></a>. <u>News.</u> Each project now (or can have) have a space 
    in which relevant news and announcements are featured. This is an advantage 
    that probably does not need to be highlighted, but say there is important 
    news relevant to the XML project. Or that the XML project lead would like 
    to keep tabs on what others in XML development are doing. The project news 
    page could be dedicated to features related to XML. For more information on 
    this, please see <a
href="http://look.openoffice.org/project/www/docs/ProjectNews.htm">http://look.openoffice.org/project/www/docs/ProjectNews.htm</a> 
  </p>
  <p> c<a name="Vc"></a>. <u>Issues.</u> Sc-OpenOffice.org makes managing issues 
    related to a project a quite a lot easier. Not only can the project lead now 
    manage issues pertaining to his or her project, but he can now more easily 
    track those issues and assign them. For more information on this, please see: 
    <a
href="http://look.openoffice.org/project/www/docs/ProjectOwnerIssues.html">http://look.openoffice.org/project/www/docs/ProjectOwnerIssues.html</a> 
  </p>
  <p> d<a name="Vd"></a>. <u>Mailing Lists.</u> There are some changes. "All project 
    mailing lists are created with anzu, an open-source mail alias and list management 
    extension of qmail simple mail transfer protocol (smtp). Anzu supports multiple 
    domains, enabling each project to define and manage its own unique set of 
    mailing lists for the project domain." This much is familiar. As is: "If you 
    created your project as a standard development project, your project begins 
    its life with five built-in, pre-configured mailing lists." What differs is 
    that it is much easier for project owners/leaders to edit mailing lists: to 
    add/delete them, as well as modify and moderate them. For more information 
    on this topic, please see: <a
href="http://look.openoffice.org/project/www/docs/ProjectOwnerMailingLists.html">http://look.openoffice.org/project/www/docs/ProjectOwnerMailingLists.html</a> 
  </p>
  <p> e<a name="Ve"></a>. <u>Source code.</u> Sc-OpenOffice.org has an option 
    whereby each project can control its own source code. To date, OpenOffice.org 
    is not so modular as that is necessary.</p>
</blockquote>
<br>
<p><a href="#top">Back to top</a> </p>
<h4> 
  VI<a name="VI"></a>. Hosted tools. </h4>
<blockquote> 
  <p> a<a name="VIa"></a>. t-OpenOffice.org's documentation page attempted to 
    consolidate information on the tools developers use, among other things. It 
    still will, but the Hosted Tools link in the Help files provide a more fluid 
    account of the hosted tools, such as CVS, IssueZilla, etc. Please see <a
href="http://look.openoffice.org/project/www/docs/hostedtools.html">http://look.openoffice.org/project/www/docs/hostedtools.html</a> 
    . (For what it is worth, OpenOffice.org is still unique in using SSH2, so 
    that element in the help files will be changed.</p>
</blockquote>
<br>
<p><a href="#top">Back to top</a> </p>
<h4> VII<a name="VII"></a>. Conclusion. </h4>
<blockquote>
  <p> a. The work that has to bed done until the new OpenOffice.org goes live 
    will focus on accommodating the legacy OpenOffice.org to the new structure. 
    For project leads, the primary focus should be on becoming familiar with managing 
    projects and project members. The help files are of inestimable value in this; 
    as are the site FAQs, which I have not touched on at all. </p>
</blockquote>

</body>
</html>