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

[Don Flinn <flinn@alum.mit.edu>]

Hi

I feel that having someone who is responsible for pulling things
together, looking for inconsistencies between different input and
assuring the the document speaks as from one voice is a good idea.  I've
co-authored some technical books and it was helpful and I might say
critical to have one of the authors take on the role of "unifier".  I
realize that this effort will not be of the size of a book, but the
basic need is still there.  My feeling is that the role as originally
described by Thomas Erl was a good description, especially the last
paragraph.  Perhaps the suggested title of the role put people off.
This person could be called something like Unifying Editor.  I also feel
that rotating this role would not be consistent with the role of
document unifier.  Lastly, this is a hard, thankless role for whoever
takes it on.

Let me get this out before it is totally obsolete with all the mail
coming in :-)

Don

On Wed, 2005-03-23 at 12:09 -0500, Matthew MacKenzie wrote:
> 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."
> >>>>
> >
> >
> 
> 
-- 
Don Flinn
President, Flint Security LLC
Tel: 781-856-7230
Fax: 781-631-7693
e-mail: flinn@alum.mit.edu
http://flintsecurity.com