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