Rex,
I don't believe that we need to create a hierarchical organization among
the editors to have a workable process. I think I outlined a way it
could be made to work in a previous email written after the one you
replied to.
I do not believe in the uber editor approach for specification
development, but I do see the value of having a rotating coordination
role. This way, we have management and process that is fair --
egalitarian even.
Thanks,
Matt
Rex Brooks wrote:
> Hi Everyone,
>
> I refrained from saying anything yesterday while I caught up on
> background materials, and notified the chair that I had not received
> the notification about yesterday's first meeting, but this happens to
> be an issue with which I have a lot of experience on all sides of the
> roles under discussion.
>
> Someone MUST take responsibility for the overall document(s). There is
> simply no way that I know of to get work done reliably and with clear
> accountability otherwise. Also, from experience, after this initial
> rush of interest dies down and the work starts becoming more humdrum
> and mundane, and everyone realistically assesses how much time such a
> task actually involves, the generosity of spirit we see now will
> inevitably diminish.
>
> Matt, as egalitarian as your ideals appear to be, I think the implied
> lack of structure as applied to a systematic approach to building a
> document or documents will simply be unworkable.
>
> Also, just as a slight adjustment to the thinking I see here, I think
> it would be best to consider the task first and worry about the credit
> later. I, for one, applaud all the volunteers, especially because I
> simply could not take on such a role with my own current commitments,
> so, however, the task of editor is eventually resolved, I think it
> bodes well for this effort that there are so many volunteers at this
> stage. Let's hope we field a stable set of editors and adopt a
> workable framework for moving the work and the document(s) forward.
>
> One suggestion as to process: please consider developing a set of real
> world business and institutional scenarios first, then develop a set
> of specific exemplar use-cases, for which I, personally, would prefer
> formal UML models, then, based on these models, derive specific,
> testable requirements in a formal Requirements Document(s) against
> which the specification(s) can be reliably tested to ensure that the
> requirements are met.
>
> I think Ken's list of questions is a good place to start to ensure we
> don't leave anything unconsidered, such as the needs of Academic
> Institutions or NGOs. Also, I understand that the underlying
> assumptions about a "Reference Model" per se, mitigate against a
> specific code-able specification or specifications, but, I think, if
> you look at similar Reference Models, such as those contained in the
> Federal Enterprise Architecture Framework, you will find that scoping
> such efforts in terms of real world examples may help us avoid some
> pitfalls. Anything we can include by reference strikes me as a good idea.
>
> I just noticed a new message that clarifies positions about UML, so I
> better post this before it becomes even more obsolete.
>
> ;-)
> Rex
>
>
>
> At 8:48 AM -0500 3/23/05, Matthew MacKenzie wrote:
>
>> Thomas,
>>
>> I am personally not in favor of having a chief editor, as I feel it
>> bestows an unfair title upon one individual of many who are working
>> on the document. The chief editor would be seen from the outside as
>> being somehow more authoritative than other editors.
>>
>> In fact, I am not in favor of having multiple "editors". I am,
>> however, all for having multiple "authors".
>>
>> -Matt
>>
>> On 22-Mar-05, at 11:08 PM, Thomas Erl wrote:
>>
>>> It's encouraging that we have six or seven individuals willing to
>>> participate as editors. Being one of them, I'm looking forward to
>>> working
>>> with you all. However, I am concerned that without a system in place
>>> for
>>> coordinating individual efforts, we may waste time and risk
>>> confusion while
>>> trying to keep everything in alignment.
>>>
>>> Our goal should always be for our collective work to facilitate the TC
>>> membership and the evolution of the reference model. I therefore
>>> agree that
>>> we should designate a chief editor to assume ultimate responsibility
>>> for the
>>> on-going quality of the reference model document and to oversee the
>>> overall
>>> collaborative process. I also believe that we should clearly define the
>>> relationships and boundaries between those that assume the role of
>>> "Editor"
>>> and the designated "Chief Editor".
>>>
>>> I've had some experience in this area, so to get things started, I've
>>> written up proposed role descriptions. Hopefully they will be
>>> helpful in
>>> getting us organized. Your feedback is welcome.
>>>
>>> Editors
>>> - Are each assigned the responsibility of maintaining a distinct and
>>> meaningful portion of the reference model.
>>> - Must be diligent in keeping their respective content areas current
>>> and
>>> representative of contributions accepted by the TC as a whole.
>>> - Maintain lists of outstanding issues specific to their content areas.
>>> - Should proof and copyedit their own work as much as possible so as to
>>> minimize the workload of the Chief Editor.
>>>
>>> Chief Editor
>>> - Ensures that the reference model document is maintained in
>>> compliance with
>>> existing OASIS documentation standards and any further conventions
>>> agreed
>>> upon by the TC.
>>> - Ensures that the predefined scope of the reference model is not
>>> exceeded.
>>> (Candidate items raised by the TC beyond the scope of the reference
>>> model
>>> should be maintained on a separate list until it is decided by the
>>> TC that
>>> these items fall within or outside the scope.)
>>> - Ensures that submissions from individual Editors are consistent in
>>> writing
>>> style, tone, terminology, and structure. (Chief Editors can either
>>> revise
>>> submissions or mark them up and then request that Editors perform the
>>> revisions. For the sake of expediency, I recommend the former
>>> approach as
>>> long as revisions are returned to individual Editors in a timely
>>> manner.)
>>> - Maintains a list of outstanding issues that apply to the document
>>> as a
>>> whole or have not yet been classified, and delegates issues to
>>> Editors when
>>> appropriate.
>>> - Maintains a parent-level outline of the reference model document.
>>> - Is responsible for version control of the reference model document
>>> and for
>>> publishing revisions to the OASIS site.
>>>
>>> Ideally, the Chief Editor would also be the one responsible for reading
>>> through position papers and other documents submitted by members to
>>> ensure
>>> that:
>>> - redundant content is filtered
>>> - content outside of the reference model scope is separated
>>> - relevant content is brought forward for consideration by the TC
>>>
>>> Because we have a sufficient amount of volunteers, I would suggest
>>> that we
>>> consider balancing the workload by limiting the duties of the Chief
>>> Editor
>>> to quality control and facilitation. This means that only individual
>>> Editors
>>> author and edit the sub-documents that comprise the reference model
>>> document. The Chief Editor is not actually assigned a separate part
>>> of the
>>> document, but instead governs the process of unifying sub-documents
>>> into the
>>> master reference model document.
>>>
>>> Regards,
>>> Thomas Erl
>>>
>>> P.S.
>>> Also of interest, from the OASIS TC Guidelines:
>>> "The TC Editor is the person who maintains the specification
>>> document(s) for
>>> the TC. The editor writes drafts, updates the drafts with input from
>>> the TC
>>> members, and makes the drafts available to TC members and to the
>>> public by
>>> posting them on the TC mail list and/or giving them to the webmaster
>>> to post
>>> on the web page. The editor should keep an ongoing list of open issues,
>>> bugs, comments, etc. and their resolution."
>>
>
>
