Re: [soa-rm] Proposed Role Descriptions for SOA-RM Editors

[Matthew MacKenzie <mattm@adobe.com>]

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."
>>
>
>