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

[Matthew MacKenzie <mattm@adobe.com>]

Rex,

Collaboration is always dificult when there is not an appropriate 
environment setup for it, as is the case at OASIS, but I won't make 
noise about that here -- Jamie understands the problems.

Frankly, we are all part timers on this specification.  Most if not all 
of us are employed full time in addition to working on other standards.  
In my opinion, it will be easier to rotate responsibility because it 
allows folks to sign up for a period of time that they can actually 
commit to, instead of having one person as a point of failure/bottleneck.

-Matt

Rex Brooks wrote:

> Hi Matt,
>
> If it works, fine. I have no inherent objection to it. I've just never 
> seen it work before, while I have seen similar efforts flounder. But, 
> regardless, as i said, if it works, fine. My experience is that 
> editors usually have the worst of all possible worlds, and very little 
> if any real power, so spreading the work out makes excellent sense as 
> long as the work gets done.
>
> Fortunately, for this TC, there is unlikely to be large, immediately 
> harmful consequences from delays and difficulties, so let's see if we 
> can make this work.
>
> Ciao,
> Rex
>
> At 11:44 AM -0500 3/23/05, Matthew MacKenzie wrote:
>
>> 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."
>>>>
>
>