[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Some details (was) Fwd ... Standards development and TC Administration staff services
> I am forwarding this to the [chairs] list, as obviously SLA issues > are of strong interest to TC leaders. Apologies for any duplicate > postings. A few comments on the execution details follow ... Needless to say, as our TC leaders, you are our first line of defense and critique regarding how we are doing and what to improve. We're already received a variety of very helpful ideas, and I hope that will continue. Please note the comment in today's announcement about transparency of service requests: "We're also considering ... making our service queue publicly archived, with each request becoming a visible, time-stamped ticket..." Doing this would make tracking one's own request a self-serve matter. Is there any reason not to do that? All of the types of requests listed in this morning's SLA table are public anyway, as they are all authorized or preceded by an open act or resolution by the TC. (We also get a lot of unofficial traffic in advice, strategic plans and hypothetical questions. I assume that will stay where it is, as point-to-point e-mail.) Second, as I hope is clear, we would appreciate receiving TC service requests to our official address, "tc-admin@oasis-open.org". We are binding our SLA commitments, most of which are significantly tighter than the rules require, to use of that address. Feel free to cc others; but for this to work well, we are making the tracking of these incoming requests better automated. The SLA times we have set are a first approximation. We don't plan to change them until we have a few months of experience with them, but that data may teach us something. Once we see how well this works for TCs and executes by staff, we may have some ideas about changing deadlines. Feedback on this is welcome. Another fundamental issue, but one that may take more thought and planning, is our heavy dependency on e-mail. A host of little notices are generated when various events occur: ballots, document uploads, TC member status changes, etc. Now, if your personal management style is to process decisions and events by managing your e-mail stream -- and it is a manageable volume -- that may work well for you. Less so, if you're not e-mail-centric. Or if you are, but are plagued with spam. Or if you receive notices from 20 committees in each of 5 standards groups. We will need to think about the long-term scalability of this approach. Finally, please note that our Board Process subcommittee is going back through the OASIS TC Process this quarter, as it does annually, looking for possible improvements. Perhaps there are rule changes that also would streamline or facilitate these transparency and speed goals. I will come back to this list with specific questions about possible rule improvement issues. For now, I simply note that our rules aren't untouchable. If a rule itself is creating an obstacle to efficient open standards work, we'd like to hear about it. Regards Jamie ~ James Bryce Clark ~ Director, Standards Development, OASIS ~ jamie.clark@oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]