[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]