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

["Brown, Al" <abrown@filenet.com>]

I agree with Don.  

As this team is made up of unique individuals with different backgrounds
and different understanding of words, it is more than likely that two
members will read the same passage and interpret it differently.

It is very important that we have one owner who moderates the
nomenclature, the terminology and for a lack of a better word normalizes
the different sections composed by different individuals into a cohesive
package.

We can have different editors or rotating editors for sections or for
even the whole document, but we need a guru who keeps all the editors in
sync.  

-Al

-----Original Message-----
From: Don Flinn [mailto:flinn@alum.mit.edu] 
Sent: Wednesday, March 23, 2005 10:56 AM
To: Matthew MacKenzie
Cc: Rex Brooks; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Proposed Role Descriptions for SOA-RM Editors

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