OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

workprocess message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Default Process: Other Committees


[pgrosso@arbortext.com:]

| I'm not paying a lot of attention to the current discussion
| (there appear to be a lot of better qualified people with more
| time than I to dedicate to this, and I trust whatever they do),
| but I don't understand any discussion of the status of past TRs.
| How can past TRs have a problematic status wrt any process being
| developed now?  In what way could their status possibly be in
| question in any way?  In what way was the process that developed
| TRs flawed or suspect?

As far as we can tell, the process by which TRs were actually approved
is completely sound.  So the original committee process is at this
point of strictly historical interest.

| >and committees of the membership (which are implied by
| >art. 13 sect. 8, second para).  
| 
| 
| All of Article 13 is about meetings of the SGML Open
| membership.  Any reference to "meeting" in this article is
| about meetings of the entire membership and have nothing to
| do with meetings of any marketing or technical committees or
| subcommittees.  Nothing in the bylaws was put there meaning
| to refer to any substructure within the marketing and
| technical tracks.

The second para of art. 13 sect. 8 puts that substructure in there.
Think of it as an entity reference.  An additional 706 pages of
procedure are pulled into the bylaws by this reference, in particular
an abundance of procedure relating to the motion to Commit.

As you will see in a subsequent message, however, we're not
considering using this, because in fact the membership can't be
depended on to form a quorum when we need one.

| The thing we called the TechCte was an email list that
| consisted of anyone who wanted to be on it.  We also had
| smaller, topic-centric email lists.  Sometimes the TechCte
| (including all those on the various subcommittees) had a
| face-to-face in which any SGML Open member could attend.
| Sometimes this collection produced a draft Technical
| Resolution that the SGML Open membership at large voted on,
| and then it became an SGML Open Techical Resolution.

As far as we can tell, this was perfectly cool.  Procedurally, it's
just as if a member had submitted a proposal to the membership at
large.  We need to start being more process-oriented at this point
because we're about to pull in other organizations and expand our
scope by a few orders of magnitude, but we're not seeing anything that
would call into question the outcomes of the previous process.

| There is nothing in the bylaws about Technical Resolutions
| either.

There doesn't have to be; that's all pulled in by expanding the
references to Robert's.  Robert's has lots to say about resolutions.

| I guess here's where I'll go back and let you folks work out
| what makes sense now.  Let me know if you want me to explain
| more what used to be or what the bylaws meant to those of us
| who signed them.

I found the material you posted illuminating, and I thank you very
much for taking the trouble to pull it together.  This answers a lot
of questions I had about how we operated as SGML Open.

Jon



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC