To be able to participate in (discussion about) our project you need to know a bit about the lingo we speak and the structure of our project. Please read all of the following subsections carefully. If you set out to be either an Editor, Author or Proofreader you consequently should read the corresonding section: Section 6.5, Section 6.7 or Section 6.4.
If after that you still do not understand how you may participate in this project, please address the Project Leader (you wil find his address in a later section), who will cheerfully answer your questions and update this document if necessary.
To enable distribution of work over many people and to prevent versioning conflicts that CVS might not be able to resolve, this book will be divided in "chunks". A "chunk" is just a block of text in the book. Chunks are written by AUTHORS but are checked into CVS by EDITORS. Note, that the Editor for a chunk may or may not be the Author of that chunk.
Anybody that can download versions of this book can become a 'Proofreader'. Proofreaders have access to the otherwise closed RSBAC-book mailing list (and its archive). To become a Proofreader one has to prove to one of the Authors or Editors to be worthy of that name by proofreading at least one chunk of the book and pointing out at least one error in it. If the Author or Editor acknowledges and corrects the error, the Project Leader is informed by the Author or Editor that has accepted the correction. The Project Leader will grant a Proofreader access to the closed mailing list and will see to it that the Proofreaders name is listed in new versions of the book in Section 6.8 and Section 6.9. Learn more about editors by studying Section 6.5.
Editors ensure that the materials they upload into CVS are consistent with the DocBook standard, and - in as much as is possible for DocBook 3.1 (SGML) documents - adhere to the guidelines for writing DocBook/XML documents. An Editor should never upload a chunk into CVS that does not comply with these standards. Editors will need to download other Editors contributions regularly and will have to test the total integrity of the book by converting the DocBook source code into HTML or Postscript, using one of the scripts provided in the CVS repository. If errors are found in chunks outside their jurisdiction, they will promptly inform the responsible Editor, so he or she can correct his chunk. Learn more about editors by studying Section 6.5.
Authors ensure that the content of the chunk is correct: an Author writes the actual content and is responsible for the validity of that content. Note, that it is entirely possible to be an Author without knowing anything about the DocBook standard nor CVS. Note, that it is entirely possible to be an Editor without knowing how to write proper educational texts. Authors will need to download other Authors contributions regularly (which of course only is possible if an Editor has uploaded these contributions first). They will proofread other Authors texts. If they find errors in chunks outside their jurisdiction, they will promptly inform the responsible Author, so he or she can correct his chunk. Authors will be appointed Editors by the Project Leader and deliver their work to the Editor. Learn more about authors by studying Section 6.7.
Anybody that can download versions of this book and is able to read and fully understand the English original and is fluent in (at least) one other language can become a 'Translator'. Translators have access to the otherwise closed RSBAC-book mailing list (and its archive). To become a translator you have to translate a part of the book into another language and send the Project Leader proof of that - for example the URL of the website where the translation can be found. Any translation is without the responsibility of the authors and should always be available under the same license as the original. The Project Leader will grant a Translator access to the closed mailing list and will see to it that the Translators name is listed in new versions of the book in Section 6.8 and Section 6.9. Learn more about translators by studying Section 6.6.
Authors are allowed to delegate parts of their chunks to other Authors. Editors are allowed to delegate part of their chunks to other Editors. Delegation of EDITORS should be reported to the Project Leader. The delegating Editor will split the chunk into proper subchunks. The projectleader will reflect these changes into the Master delegation file. If the delegated work has been finished, the delegating Editor will reassemble the subchunks into one chunk and inform the Project Leader, who will again update the Master file to reflect the change. Delegation of Authors is transparant to the other project members: the Author will have to reassemble the delegated work and hand over his work as a whole to his Editor.
Any problems regarding the technical consistency of the book that could not be resolved within a week by the Editors will become the problem of the Master Editor. The Master Editor will investigate the problem and try to pinpoint the Editor responsible for the problem. If just one Editor causes the problem, the Master Editor will respectfully inform that Editor of the nature of the problem and will offer assistence to that Editor to help him resolve the problem. If the problem is caused by 2 or more Editors the Master Editor will inform all Editors involved and appoint an Editor to resolve the matter. Since the Master Editor can be an Editor, he may be able to appoint himself. Additionally, the Master Editor is responsible for the integral quality of the DocBook code used in releases of the book.
Any problems regarding the correctness of the content of the book that could not be resolved within a week by the Authors will become the problem of the Master Author. The Master Author will investigate the problem and try to pinpoint the Author responsible for the problem. If just one Author causes the problem, the Master Author will respectfully inform that Author of the nature of the problem and will offer assistence to that Author to help him resolve the problem. If the problem is caused by 2 or more Authors the Master Author will inform all Authors involved and appoint an Author to resolve the matter. Since the Master Author can be an Author, he may be able to appoint himself. Additionally, the Master Author is responsible for the integral quality of the content in releases of the book.
The Project Leaders guides the project. He issues and discusses guidelines and procedures. He resolves problems that can not be resolved by either the Master Author or Master Editor. He also acts as the spokesperson for the project and is the maintainer of this file and maintains the closed mailinglist for Proofreaders, Editors and Authors.
Often, people can be identified uniquely by their (full) names. However, sometimes that does not apply, for example when we have two people with the same name. To enable us to uniquely identify each Project Member, he/she is appointed a handle by the Project Leader. All handles ever issued are listed in this book in Section 6.8. Currently the handles are sequences of three capital letters - which means that we can uniquely identify 17576 people. The Project Leader will try to assign you a handle that matches your name (e.g. your initials) or you can suggest a handle. If the handle is available it will be appointed to you. Else, the first free handle that is in the suggested range will be appointed to you.
Writing chapters, reviewing them, maintaining support software, creating websites ... all that and more are tasks within our project. To maintain an overview of the tasks and to enable prioritisation of them, the Project Leader is responsible for maintaining a TODO list. That list is accessible for everyone with CVS access (discussed before in Section 6.2) and can be found in the subdirectory /project/. It should be kept in a strict format, which is documented in the TODO file itself. As you may have guessed: the list is also used by a number of programs, hence the strict adherence to a standard format. These programs are part of the CVS tree too and can be found under /project/software. One of these programs /project/software/scan/genmail generates weekly remainders for the Project Members and mails these to them.
A task is a set of (related) work that should be performed in order to help create a (better) set of books. A task typically is created if one of the Project Members signals that something needs to be done. Usually the task is discussed on the mailing list first. If it is not something that requires immediate attention and if the general feeling is that the task should be performed, it is entered (by the Project Leader) on the TODO list. Each task will then become an item on the TODO list. Items are formalised descriptions of tasks. They have unique numbers to enable unobfuscated identification (the item number), somebody will sooner or later take responsibility for it so we have to have a placeholder for his/her handle, a priority needs to be given to it (a number from 1-9: 1 suggests very high priority) and we have to track the date it was entered and the date it was completed. A description of the task is of course part of the item too.
Apart from tasks we also talk about events sometimes. An event is a task that needs to be completed with utmost priority - in fact: it can not wait for completion long enough to enter in as an item in our TODO list. Often the person that handles an event already handled it even before being able to report about it on the mailing list. Events are and should be exceptional. An example of such an event is the correction of a syntax error in one of the DocBook source files. Under normal circumstances Editors test the correctness of the entire set (including the modifications) before commiting changes to CVS. If for some reason that was not done an event occurs: the person that is responsible for uploading the erroneous version should immediately correct it.
[* Grabbers are unassigned items/tasks TBW]
[* TBW]