|
Replies:
31
-
Last Post:
Dec 16, 2008 2:25 PM
by: kupfer
|
Threads:
[
Previous
|
Next
]
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
[ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 7, 2008 2:10 AM
|
|
hey ...
Here's a start at a new Constitution. I kept (but heavily edited) some
of the current Constitution (mostly the OGB section), combined other
parts, and I removed entire sections that were either confusing or that
may not fit with our future. We tend to ignore those sections, anyway,
so it makes no sense to keep them. The sections below aren't
necessarily complete, but I intentionally stripped things down so we
can decide if we want to build up in areas or just leave things on the
thin side.
After reading the current Constitution line by line and trying to fit
the new OGB reorg documents into it, I found it painfully obvious that
we need to start fresh. So, I encourage you to comment on this as a
rough base and not necessarily try to fit bits from the old document
into this one. In fact, I encourage you to take more stuff /out/ of
this draft, especially in the OGB section. Let's build up based on how
we are working currently. But if there is a good idea from the old
document that I inadvertently deleted, that's fine, please rewrite it
in plain language and work it in and we can discuss it. I also
encourage you to not word smith this thing. It's far too early for
that, and we have a long history of wording ourselves to death.
Remember, we have no legal standing, and we are not running a country.
This document should simply articulate the structure of the community
and how it functions, and it should not be expected to cover all
possible scenarios. We'll deal with things as they come up. Finally, we
should flush out the concepts on list for a few weeks and elect one
person to write/copyedit the final document so it has one style
throughout. You'll see that this initial draft has several distinct
voices, which isn't good.
That's it ...
Jim
The OpenSolaris Constitution: (Really Rough) v2.0
Overview
This constitution outlines the basic structure and operations of the
OpenSolaris community and the OpenSolaris Governing Board (OGB), both
of which were initiated by Sun Microsystems on June
14, 2005. Also, this Constitution was updated to version 2 in March
2009, and
previous versions can be found with the OGB.
Groups and Roles
Groups. The OpenSolaris
community is structured as an organization of participants in
which Members are given the right to vote on community-wide decisions,
the most significant of which is to elect the OGB. The OGB, in turn,
delegates the organization, operations, and decision-making processes
for OpenSolaris activities to community members in four groups. The
groups are defined as the following:
- Communities: Social groups gathered around issues or
technologies.
- Projects: Development groups gathered around code repositories
and integration tools.
- User Groups: Groups of users gathered around issues or
technologies in a specific geography.
- Electorate: The group of voting members of the overall
OpenSolaris community.
Roles. There are three roles in
the OpenSolaris community:
- Participants: Those who are registered on opensolaris.org are
eligible to be participants in a user group, project, or community.
- Contributors: Those who have been recognized as having
substantially helped with the goals of a given group. That person would
have been allowed by a group to edit web pages, commit code directly to
a project gate, or help moderate a mailing list, for example. Each user
group, project, and community may have their own set of standards for
recognizing a person as a contributor.
- Leaders: Those who have the responsibility of leading a user
group, project or community. For example, they may have the final say
to wrap up discussions, or they may decide the technical direction of a
given project. Leaders may appoint participants to the level of
contributor. Leaders may also appoint participants/contributors to the
level of leader. Each user group, project, and community may have their
own set of standards by which a person is recognized as a leader.
Creating Communities, Projects, and User Groups
Overview: Groups can be
created, archived, reactivated and changed. All groups are considered
equal, and there is one process to create all groups.
Group Creation Process
- Go to http://defect.opensolaris.org
- Create a new "bug" under Community > Infrastructure >
Create with the following information
- Your opensolaris.org user ID (required)
- Type (Community, Project, User Group)
- Community Name
- Title
- Description
- Leaders (opensolaris.org user IDs required)
- Mailing List Requirements
- Someone other than yourself with an Opensolaris.org user ID needs
to
vote for the "bug" you just created. Group requests will only be
accepted once they have one or more votes from people other than the
originator.
- Wait. As someone becomes available, your request will be
processed by one of the admin team and you will be notified.
Group Type Change
- Go to http://defect.opensolaris.org
- Create a new "bug" under Community > Infrastructure >
Change with the following information
- Your opensolaris.org user ID (required)
- Community Name
- New Type (Community, Project, User Group)
- Rationale/context
- Wait. As someone becomes available, your request will be
processed by one of the admin team and you will be notified.
Archiving
>From time to time, a group may become dormant. But since it's never a
desirable situation to have unmaintained infrastructure on the web,
there is a process for archiving groups. If there has been no activity
from a group for six months, or at the discretion of the OGB or its
nominated committee acting in the interests of the community, the
following may happen:
- Mailing list changed to 'no subscriptions' [note: may need to
note Jive forum status here too]
- Web page visibly tagged with 'Dormant'
- List of leaders/participants reset to zero
- SCM write disabled
Reactivating
- Go to http://defect.opensolaris.org
- Create a new bug under Community > Infrastructure >
activate with the following information
- Name
- Reasons to activate
- Leaders (preferably opensolaris.org user IDs)
- Wait. As someone becomes available, your request will be
processed by one of the admin team and you will be notified.
Mailing Lists
Mailing list names should indicate purpose, and have one of the
following suffices:
- -dev: developer discussion
- -discuss: general discussion
- -notify: notification alias for SCM putbacks
Private mailing lists may be granted in exceptional circumstances, but
full rationale is required and the OGB must approve. Although this
process is intended to be essentially automatic, the OGB will form a
committee with oversight and with the power to veto group requests if
it is in the interests of the community. Finally, all notifications to
bugs in Community > Infrastructure
> Creation will be sent to group-creation at opensolaris dot org.
Membership
Membership: The OpenSolaris
Membership is held in the Electorate group. Participants, Contributors,
and Leaders from User Groups, Projects, and Communities may become
associated with the Electorate group, and once included, are
collectively responsible for the global well-being of the OpenSolaris
project. Association with the Electorate is opt-in, and successful
association is classified as becoming a Member of the OpenSolaris
community. Only those who have substantially and verifiably contributed
to an existing User Group, Project, or Community may apply for
OpenSolaris Membership. The Membership elects a set of Leaders for the
community on an annual basis to form the OGB. Association with the
Electorate group has no bearing on your involvement in existing User
Groups, Projects, or Communities.
Membership Process:
- Go to http://membership.opensolaris.org/
- Apply for membership with the following information
- Full Name
- OpenSolaris user ID
- For each collective to which you substantially contribute:
- Identify the collective
- Identify which Leader in that collective can validate your
claim of substantial contribution
- If you cannot identify a Leader, identify the user IDs of at
least two
existing Members of the Electorate who may vouch for your activity
- Wait. As and when your application gets processed you will be
notified.
- The Membership Committee is a Board Committee (chaired by an
OGB member
but open to any Member of the electorate) and has been delegated by the
OGB to determine who may and may not be granted Member status. They are
responsible to the OGB for administering this process.
- The Leader(s) you identified above will be asked to verify your
claim
online. If they do so, your Member status will be granted automatically
(or, if a "quiet period" before an election is in place, at the end of
that period)
- If you did not identify any Leaders, the Members you identified
will be
asked to vouch for you online. The Membership Committee will then
validate your request and in all but exceptional cases grant Member
status.
- If your referees do not validate your claim within thirty days,
your application will be rejected.
3.3: Duration: Qualification
for Membership is for life. However, you need to renew every two years.
If you don't renew, you are removed from the current list of voters,
but a record of your previous membership is maintained. You can
reactivate your Membership up to 14 days after a community wide
election is announced.
Meetings of Members
Annual Meeting. A Meeting
of the Members shall be held annually to elect the OGB and ratify
Constitutional changes. The OGB shall provide notice to the community
not less than ten days or more than sixty days before the date of
the meeting. One-third of the Members,
represented in person or represented by proxy, shall constitute a
quorum. If a quorum is present, the affirmative
vote of a majority of the Members represented at the meeting shall be
the act of the members.
Voting. Each Member shall be
entitled to one vote on each matter
submitted at a meeting of the members. A Member may vote in
person, by proxy executed in writing by the member, or, when a vote is
conducted by electronic ballot, by submitting a completed ballot to the
voting mechanism.
Proxies. Every Member may
authorize another person or persons to
act for said Member by proxy. Every proxy must be signed by the Member
and delivered to the Secretary. No proxy shall be valid after one
year from its date, unless otherwise provided in the proxy. All proxies
shall be revocable.
Minutes. The minutes of any
meeting of the Members shall be
posted in a public forum within thirty (30) days of the meeting. A
record of any Member action by written consent shall be posted in a
public forum within thirty (30) days of the action having taken effect.
Governing Board
OGB The OGB's role is to
provide guidance and leadership for the OpenSolaris community, to
maintain the community's Constitution, to run elections, and to help
mediate disputes. The OGB shall consist of a minimum of three and a
maximum of seven people. OGB members, upon change of corporate
affiliation or other
interests related to OpenSolaris, must notify the membership of their
new status.
Election and Term. At the
annual meeting of Members, the Members shall elect OGB members to
hold office starting the first day of the
calendar month following the election and continuing until the first
day of the calendar month following the next annual meeting.
Each OGB member shall hold office for the term for which he or she is
elected, until his or her successor shall have been elected, or until
his or her earlier resignation, removal, or death. OGB members can
serve for three consecutive terms.
Candidates. Candidates for
election to the OGB must be nominated by a current
Member. Nominations shall be open for a minimum of seven days prior
to ballot completion. An OGB election ballot must be complete and
publicly viewable no less than seven days prior to the start of
voting. Once voting has started, the voting shall remain open for at
least seven days. Candidates for election shall publish a list of their
commercial
affiliations, or other interests related to OpenSolaris, so that a
voting member can understand the context from which they would act on
the OGB and the likely biases they would bring. Candidates who before
the start of voting do not publish such a statement and attest to its
accuracy shall not be eligible for election. The Secretary of the OGB
shall maintain a public register of OGB Members' interests.
Resignation
and Removal of OGB Members. An OGB member may resign upon
written request to the OGB. An OGB member may be
removed, with or without cause, by an affirmative vote of two-thirds of
the Members. Also, an affirmative vote of a
majority of the Members expressing "no confidence" in the
current OGB, or an act by the entire OGB to resign from office, shall
have the effect of requiring a special election to be held for a
replacement OGB within thirty days of such act.
Vacancies. In the event of a
resignation or death, the OGB shall review the ballot results of the
previous
OGB election and appoint the next available candidate to fill the
vacancy. In the event that there are no further candidates from the
prior election, or if the vacancy is due to the removal of an OGB
member, the vacancy shall not be filled until the next OGB election.
Quorum and Voting. A
majority of the OGB members in office
shall constitute a quorum. The vote of
a majority of the OGB members present at a meeting at which a quorum is
present shall be the act of the OGB. The OGB election shall be
conducted according to the balloting method known as Single
Transferable Vote,
specifically using the Meek algorithm.
Meetings.
Meetings of the OGB
shall be held following the annual meeting of the Members and
thereafter. Meetings should not be more than three months apart.
Meetings may be
held in person or via a shared teleconference, IRC, or equivalent
medium for shared communication by means of which all persons
participating in the meeting can hear or read each others' comments at
the same time. OGB meetings are, in general, open to attendance
by any Members provided that such attendance does not interfere with
the OGB members. The OGB may, when appropriate,
choose to discuss confidential items in a closed
session, but any decisions resulting from such discussion
must be approved in open session.
Officers. The officers of the
OGB shall consist of a Chair, a
Vice-Chair, and a Secretary, each of whom shall be appointed by the
OGB.
The offices of Chair and Vice Chair must be held by OGB members. The
office of Secretary need not be
held by an OGB member. The officers shall have the following duties:
- The Chair shall preside at all meetings of the
Members and OGB.
- The Vice Chair shall, in the absence or disability
of the Chair, perform the duties and exercise the powers of the Chair.
- The Secretary shall keep accurate records of the proceedings of
all meetings of the Members and of the OGB, and make such records
available
to OpenSolaris Participants. The Secretary shall have general charge of
the membership records of the OpenSolaris Community and shall keep a
record of the Members that shall include each Member's participant
identifier, name, and electronic mail address.
Board Committees. The OGB may
designate any number of
Board Committees, each consisting of at least one OGB member and
composed of persons appointed by the OGB.
Disputes
Disputes. Disputes among
participants shall be resolved by the respective group according to its
normal decision-making procedures. If a dispute extends into to the
OpenSolaris community at-large, then the participants may appeal to the
OGB.
Suspension of Participants.
The OGB is responsible for ensuring that participation in the
OpenSolaris community is constructive. When abuse is reported to the
OGB, the OGB will review a participant's actions in the following way:
- The OGB will notify the participant that his or her participation
in the OpenSolaris community is under review and that the review will
be completed within thirty days. The review should occur in a closed
session and remain private unless an action is made to suspend the
participant.
- The OGB may order a temporary removal of the participant's write
access to the OpenSolaris community infrastructure until the review is
complete.
- Upon conclusion of the review, the OGB may vote to suspend the
participant's write access to the OpenSolaris community infrastructure
for up to six months. If the participant has previously been subjected
to a suspension, the OGB may recommend expulsion.
- A suspended member may attend and vote at a meeting of the
members, in person or by proxy, subject to the normal rules of conduct
for that meeting.
Expulsion of Participants.
A participant under suspension may be expelled from the OpenSolaris
community by an affirmative vote of a two-thirds majority of the
members. The effect of a removal shall be the immediate expiration of
all grants of membership status and removal of the participant's write
access to the OpenSolaris community infrastructure until a
subsequent act of the members revokes the expulsion.
Amendments
This Constitution may be updated or
repealed by an affirmative vote of a majority of the Members
during annual meetings
Dissolution
If the OGB is reduced in membership below the minimum of three members,
Sun Microsystems shall appoint a new board.
<pre class="moz-signature" cols="72">--
http://blogs.sun.com/jimgris/
http://twitter.com/jimgris/
</pre>
|
|
|
Posts:
6,807
From:
US
Registered:
3/9/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 7, 2008 5:33 AM
in response to: jimgris
|
|
Jim Grisanzio writes:
> Here's a start at a new Constitution. I kept (but heavily edited) some
> of the current Constitution (mostly the OGB section), combined other
> parts, and I removed entire sections that were either confusing or that
> may not fit with our future.
For the benefit of the members who'll need to vote on this, I suggest
creating a companion document (nothing fancy; a few paragraphs should
do) that explains exactly what parts were kept, removed, and changed,
so that those voting know what they're being asked to do and don't
have to attempt a visual 'diff' between the two. The content and
layout seems a bit different, and it's going to be hard to get
agreement without some kind of guide.
> long history of wording ourselves to death. Remember, we have no legal
> standing, and we are not running a country. This document should simply
True, it's nothing as weighty as that, but I'd argue that precision is
still very important if you hope to have consensus. A lack of
precision is exactly what gets us into those disagreements, and in
that regard, the global significance of this group (or lack of it)
makes no difference. Be precise, so that we don't have to argue
later.
> Mailing list names should indicate purpose, and have one of the
> following suffices:
>
> * -dev: developer discussion
> * -discuss: general discussion
> * -notify: notification alias for SCM putbacks
This list of suffixes seems way too detailed to be here as more than a
suggestion. I'm not sure what "should" means above, but I'd hope that
this doesn't cause headaches for projects that would like to have
(say) 'projname-review' for discussing code review comments. As long
as the name is descriptive, reasonably non-offensive
("username-die-die-die" might be popular, but probably should not be
allowed), and doesn't tromp on some other group's name space, I'd
rather see groups decide on their own what individual mailing lists
make sense for them.
Better still, put infrastructure in place (mailman administrative
rights) that will allow 'leaders' to create new mailing lists of the
form "${GROUP}-.*" without needing to go through any special process.
> Private mailing lists may be granted in exceptional circumstances, but
I'm not exactly sure what "private" means here, but I suspect I
disagree with this as a matter of policy. We should have no explicit
policy that allows groups to create private lists on opensolaris.org
infrastructure, nor any reason to allow one except perhaps for OGB
administrative purposes (which are logically outside of normal group
processes).
What is "open" about making room for secret discussions among
developers?
The current constitution has an explicit exception for private lists,
but it's one that (as best I can tell) we've never used, and very
likely could *NOT* use. The current exception allows lists for
discussing security vulnerabilities (which I think is probably
complete nonsense, as the restrictions we have on that sort of
information make it rather imprudent to post to a server outside of
the SWAN), and for administrative use of groups (likely never used,
and mostly rendered moot by the new processes this document
describes).
If someone really needs a private list, there are *plenty* of third-
party places to have such a list, and it's quite likely that the folks
who have this need already have the infrastructure for it; you don't
need much more than a single PC running Solaris and mailman. Also, if
those folks need to be secretive, they'd probably be better served by
a private service anyway, rather than hiding out in one corner of a
public system.
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 7, 2008 9:15 AM
in response to: carlsonj
|
|
James Carlson wrote:
> Jim Grisanzio writes:
>
>> Here's a start at a new Constitution. I kept (but heavily edited) some
>> of the current Constitution (mostly the OGB section), combined other
>> parts, and I removed entire sections that were either confusing or that
>> may not fit with our future.
>>
>
> For the benefit of the members who'll need to vote on this, I suggest
> creating a companion document (nothing fancy; a few paragraphs should
> do) that explains exactly what parts were kept, removed, and changed,
> so that those voting know what they're being asked to do and don't
> have to attempt a visual 'diff' between the two. The content and
> layout seems a bit different, and it's going to be hard to get
> agreement without some kind of guide.
>
I agree. I tried to do a line by line diff, but it became too messy
since the new document is not really based on the old one. But for any
voting on a new Constitution, we'll need a document explaining the
transition so it's clear what has been changed and why. For now, I just
put this out for discussion. I expect this to evolve greatly.
>> long history of wording ourselves to death. Remember, we have no legal
>> standing, and we are not running a country. This document should simply
>>
>
> True, it's nothing as weighty as that, but I'd argue that precision is
> still very important if you hope to have consensus. A lack of
> precision is exactly what gets us into those disagreements, and in
> that regard, the global significance of this group (or lack of it)
> makes no difference. Be precise, so that we don't have to argue
> later.
>
I know, but I'd rather get to the precision later. :) And also, I'd
really like to keep the language in the new document as plain as
possible, but many people will argue that that style will lack
precision. We'll have to see. For instance, I find the current
Constitution extremely detailed, and in many areas very precise, but
it's difficult to read and people argue over a great deal of what's in
there.
>> Mailing list names should indicate purpose, and have one of the
>> following suffices:
>>
>> * -dev: developer discussion
>> * -discuss: general discussion
>> * -notify: notification alias for SCM putbacks
>>
>
> This list of suffixes seems way too detailed to be here as more than a
> suggestion. I'm not sure what "should" means above,
I'm not sure if Glynn (this came from Glynn's draft of the project
creation process) is suggesting this as a guideline or if it is meant to
be the rule. It's probably a guideline.
> but I'd hope that
> this doesn't cause headaches for projects that would like to have
> (say) 'projname-review' for discussing code review comments. As long
> as the name is descriptive, reasonably non-offensive
> ("username-die-die-die" might be popular, but probably should not be
> allowed), and doesn't tromp on some other group's name space, I'd
> rather see groups decide on their own what individual mailing lists
> make sense for them.
>
> Better still, put infrastructure in place (mailman administrative
> rights) that will allow 'leaders' to create new mailing lists of the
> form "${GROUP}-.*" without needing to go through any special process.
>
>
>> Private mailing lists may be granted in exceptional circumstances, but
>>
>
> I'm not exactly sure what "private" means here, but I suspect I
> disagree with this as a matter of policy. We should have no explicit
> policy that allows groups to create private lists on opensolaris.org
> infrastructure,
I would tend to agree, but the OGB agreed to that in the project
creation process (which is why it's in here). I'll have to go back and
look at the notes of that meeting to see the arguments.
Thanks for the comments. One of the goals here is to see how all these
new bits fit together (or not).
Jim
--
http://blogs.sun.com/jimgris/
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Stephen Lau
stevel@opensolaris.org
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 7, 2008 9:56 AM
in response to: jimgris
|
|
On 10/7/08 9:15 AM, Jim Grisanzio wrote:
> James Carlson wrote:
>
>>> Mailing list names should indicate purpose, and have one of the
>>> following suffices:
>>>
>>> * -dev: developer discussion
>>> * -discuss: general discussion
>>> * -notify: notification alias for SCM putbacks
>>>
>>>
>> This list of suffixes seems way too detailed to be here as more than a
>> suggestion. I'm not sure what "should" means above,
>>
>
> I'm not sure if Glynn (this came from Glynn's draft of the project
> creation process) is suggesting this as a guideline or if it is meant to
> be the rule. It's probably a guideline.
>
>
My impression was that it was a guideline. I'd suggest leaving it out
of the Constitution, and putting it in a "Group Guidelines" document as
suggestions for helping people bootstrap a Community, Project, or User
Group.
cheers,
steve
--
stephen lau | stevel at opensolaris dot org | www.whacked.net
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 8, 2008 12:18 AM
in response to: Stephen Lau
|
|
On 10/08/08 01:56, Stephen Lau wrote:
> On 10/7/08 9:15 AM, Jim Grisanzio wrote:
>>
>> I'm not sure if Glynn (this came from Glynn's draft of the project
>> creation process) is suggesting this as a guideline or if it is meant to
>> be the rule. It's probably a guideline.
>>
>>
> My impression was that it was a guideline.
Ok, cool. Thought so.
> I'd suggest leaving it out of the Constitution, and putting it in a
> "Group Guidelines" document as suggestions for helping people
> bootstrap a Community, Project, or User Group.
>
Agree.
Jim
--
http://blogs.sun.com/jimgris/
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
442
From:
US
Registered:
6/16/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 7, 2008 8:51 AM
in response to: jimgris
|
|
For what it is worth coming from me: On Tue, Oct 7, 2008 at 4:10 AM, Jim Grisanzio <Jim dot Grisanzio at sun dot com> wrote:
Creating Communities, Projects, and User Groups
Overview: Groups can be
created, archived, reactivated and changed. All groups are considered
equal, and there is one process to create all groups.
Group Creation Process
- Go to http://defect.opensolaris.org
- Create a new "bug" under Community > Infrastructure >
Create with the following information
- Your opensolaris.org user ID (required)
- Type (Community, Project, User Group)
- Community Name
- Title
- Description
- Leaders (opensolaris.org user IDs required)
- Mailing List Requirements
- Someone other than yourself with an Opensolaris.org user ID needs
to
vote for the "bug" you just created. Group requests will only be
accepted once they have one or more votes from people other than the
originator.
- Wait. As someone becomes available, your request will be
processed by one of the admin team and you will be notified.
Group Type Change
- Go to http://defect.opensolaris.org
- Create a new "bug" under Community > Infrastructure >
Change with the following information
- Your opensolaris.org user ID (required)
- Community Name
- New Type (Community, Project, User Group)
- Rationale/context
- Wait. As someone becomes available, your request will be
processed by one of the admin team and you will be notified.
Archiving
>From time to time, a group may become dormant. But since it's never a
desirable situation to have unmaintained infrastructure on the web,
there is a process for archiving groups. If there has been no activity
from a group for six months, or at the discretion of the OGB or its
nominated committee acting in the interests of the community, the
following may happen:
- Mailing list changed to 'no subscriptions' [note: may need to
note Jive forum status here too]
- Web page visibly tagged with 'Dormant'
- List of leaders/participants reset to zero
- SCM write disabled
Reactivating
- Go to http://defect.opensolaris.org
- Create a new bug under Community > Infrastructure >
activate with the following information
- Name
- Reasons to activate
- Leaders (preferably opensolaris.org user IDs)
- Wait. As someone becomes available, your request will be
processed by one of the admin team and you will be notified.
Mailing Lists
Mailing list names should indicate purpose, and have one of the
following suffices:
- -dev: developer discussion
- -discuss: general discussion
- -notify: notification alias for SCM putbacks
Private mailing lists may be granted in exceptional circumstances, but
full rationale is required and the OGB must approve. Although this
process is intended to be essentially automatic, the OGB will form a
committee with oversight and with the power to veto group requests if
it is in the interests of the community. Finally, all notifications to
bugs in Community > Infrastructure
> Creation will be sent to group-creation at opensolaris dot org.
I'm wondering if codifying the procedures and policy for group et al creation is appropriate here. As I think James C. alluded to, there's a lot of detail here, and I worry that presenting this much detail into this type of document will make changes or evolution of those procedures much more difficult. As this is a "constitution", ostensibly changing anything here would seem a heavyweight ordeal.
How about something along the lines of "Creation of <<stuff>> is governed by the current <<stuff>> creation policy, found at hxxp:// policies.opensolaris.org/stuff ", and delegate ownership and management of that either to a committee or just call out it's governance model here.
I'm not disputing this section's accuracy or importance, just respectfully questioning its presence in *this* document with the default constitution changing procedures required to change it.
Dissolution
If the OGB is reduced in membership below the minimum of three members,
Sun Microsystems shall appoint a new board.
Was there discussion about modifying this? I can't seem to find it.
Respectfully submitted, Mark
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
6,807
From:
US
Registered:
3/9/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 7, 2008 9:19 AM
in response to: devnull
|
|
Mark Martin writes:
> How about something along the lines of "Creation of <<stuff>> is governed by
> the current <<stuff>> creation policy, found at hxxp://
> policies.opensolaris.org/stuff", and delegate ownership and management of
> that either to a committee or just call out it's governance model here.
I think that'd be a reasonable alternative. You're right that there
seems to be too much low-level detail here (such as the spelling of
the mailing list names), and given the intentional level of difficulty
in changing this document, that's not a good thing.
I think the authors of this new one, though, want "one stop shopping."
> Dissolution If the OGB is reduced in membership below the minimum of three
> > members, Sun Microsystems shall appoint a new board.
> >
>
> Was there discussion about modifying this? I can't seem to find it.
That's one of the reasons I wanted an overview of or guide to the
changes. The current constitution says:
If, for any reason, the OGB is reduced in membership below the
Charter's required minimum of three (3) OGB members, custody of the
OpenSolaris Community shall revert to Sun Microsystems, Inc., until
such time as the Members elect a new OGB or the Charter is
dissolved.
Note that it says "Members" and not "Sun." For a revised
constitution, I think the new language is a lot less precise, in part
because Sun Microsystems doesn't take actions (its officers and
employees do), and because it's unclear how that case would work.
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 7, 2008 9:27 AM
in response to: devnull
|
|
Mark Martin wrote:
>
> I'm wondering if codifying the procedures and policy for group et al
> creation is appropriate here. As I think James C. alluded to, there's
> a lot of detail here, and I worry that presenting this much detail
> into this type of document will make changes or evolution of those
> procedures much more difficult. As this is a "constitution",
> ostensibly changing anything here would seem a heavyweight ordeal.
>
> How about something along the lines of "Creation of <<stuff>> is
> governed by the current <<stuff>> creation policy, found at
> hxxp://policies.opensolaris.org/stuff
> <http://", and delegate ownership and
> management of that either to a committee or just call out it's
> governance model here.
>
> I'm not disputing this section's accuracy or importance, just
> respectfully questioning its presence in *this* document with the
> default constitution changing procedures required to change it.
I think you are right. I thought about that only after I finished and
saw how long it was. :) My own view is that the document should be short
enough that people wouldn't mind reading it and following it. But what
you are saying is that it should point to other docs for more specifics.
I agree (after the fact). It was helpful, to me anyway, to try to merge
the documents into one because I found things that confused me or that I
didn't agree with. So, for the purposes of discussion, and since we
didn't get too much feedback on the reorg documents, let's see what
other feel but perhaps move to more of a model you suggest.
> Dissolution
>
> If the OGB is reduced in membership below the minimum of three
> members, Sun Microsystems shall appoint a new board.
>
>
> Was there discussion about modifying this? I can't seem to find it.
No specific discussion on this. I was just editing for length and/or
style. I had intended to keep in "until such time as the Members elect a
new OGB or the Charter is dissolved" ... so Sun would have to appoint a
new board, an election would take place, and we'd go on. I took out all
references to the Charter, too, because I think that has to be
considered separately.
Thanks ...
Jim
--
http://blogs.sun.com/jimgris/
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Stephen Lau
stevel@opensolaris.org
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 7, 2008 9:54 AM
in response to: jimgris
|
|
Thanks for putting this together so quickly Jim, comments inline...
> Roles. There are three roles in the OpenSolaris community:
>
> 1. Participants: Those who are registered on opensolaris.org are
> eligible to be participants in a user group, project, or community.
> 2. Contributors: Those who have been recognized as having
> substantially helped with the goals of a given group. That
> person would have been allowed by a group to edit web pages,
> commit code directly to a project gate, or help moderate a
> mailing list, for example. Each user group, project, and
> community may have their own set of standards for recognizing a
> person as a contributor.
> 3. Leaders: Those who have the responsibility of leading a user
> group, project or community. For example, they may have the
> final say to wrap up discussions, or they may decide the
> technical direction of a given project. Leaders may appoint
> participants to the level of contributor. Leaders may also
> appoint participants/contributors to the level of leader. Each
> user group, project, and community may have their own set of
> standards by which a person is recognized as a leader.
>
While the "Leader" role is clearly scoped to a user group, project, or
community - it's not immediately clear to me from the definition of the
Contributor role what it's scope is. Perhaps, "That person is allowed
by a group to edit the group's web pages, commit code to the group's
gate, or help moderate its mailing lists" ?
>
>
> Creating Communities, Projects, and User Groups
>
> Overview: Groups can be created, archived, reactivated and changed.
> All groups are considered equal, and there is one process to create
> all groups.
>
> Group Creation Process
>
> 1. Go to http://defect.opensolaris.org
> 2. Create a new "bug" under Community > Infrastructure > Create
> with the following information
> 1. Your opensolaris.org user ID (required)
> 2. Type (Community, Project, User Group)
> 3. Community Name
> 4. Title
> 5. Description
> 6. Leaders (opensolaris.org user IDs required)
> 7. Mailing List Requirements
> 3. Someone other than yourself with an Opensolaris.org user ID
> needs to vote for the "bug" you just created. Group requests
> will only be accepted once they have one or more votes from
> people other than the originator.
> 4. Wait. As someone becomes available, your request will be
> processed by one of the admin team and you will be notified.
>
Perhaps we should define the "Admin" team, since that will surely raise
questions for people inquiring about status.
>
>
> Archiving
>
> >From time to time, a group may become dormant. But since it's never a
> desirable situation to have unmaintained infrastructure on the web,
> there is a process for archiving groups. If there has been no activity
> from a group for six months, or at the discretion of the OGB or its
> nominated committee acting in the interests of the community, the
> following may happen:
>
> * Mailing list changed to 'no subscriptions' [note: may need to
> note Jive forum status here too]
> * Web page visibly tagged with 'Dormant'
> * List of leaders/participants reset to zero
> * SCM write disabled
>
There might be historical value in having the leaders/participants left
intact. Is there any harm in doing so?
>
>
> Disputes
>
> Disputes. Disputes among participants shall be resolved by the
> respective group according to its normal decision-making procedures.
> If a dispute extends into to the OpenSolaris community at-large, then
> the participants may appeal to the OGB.
Maybe explicitly define the scope to the group:
"Disputes among participants within a Community, Project, or User Group
shall be resolved by the respective group according to its normal
decision-making procedures. If a dispute needs escalation beyond that
group (i.e. if it extends into the OpenSolaris community at-large, or
crosses group boundaries), then the participants may appeal to the OGB"
> Suspension of Participants. The OGB is responsible for ensuring that
> participation in the OpenSolaris community is constructive. When abuse
> is reported to the OGB, the OGB will review a participant's actions in
> the following way:
>
> 1. The OGB will notify the participant that his or her
> participation in the OpenSolaris community is under review and
> that the review will be completed within thirty days. The review
> should occur in a closed session and remain private unless an
> action is made to suspend the participant.
>
Is it the OGB or the Member Board that reviews the participant?
>
> 1. The OGB may order a temporary removal of the participant's write
> access to the OpenSolaris community infrastructure until the
> review is complete.
>
I think we should call out the specifics (e.g. does write access include
the ability to post to mailing lists? Or just code repositories?)
>
> 1. Upon conclusion of the review, the OGB may vote to suspend the
> participant's write access to the OpenSolaris community
> infrastructure for up to six months. If the participant has
> previously been subjected to a suspension, the OGB may recommend
> expulsion.
> 2. A suspended member may attend and vote at a meeting of the
> members, in person or by proxy, subject to the normal rules of
> conduct for that meeting.
>
Really?
cheers,
steve
--
stephen lau | stevel at opensolaris dot org | www.whacked.net
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 8, 2008 12:13 AM
in response to: Stephen Lau
|
|
On 10/08/08 01:54, Stephen Lau wrote:
<pre wrap="">Thanks for putting this together so quickly Jim, comments inline...
</pre>
<pre wrap="">Roles. There are three roles in the OpenSolaris community:
1. Participants: Those who are registered on opensolaris.org are
eligible to be participants in a user group, project, or community.
2. Contributors: Those who have been recognized as having
substantially helped with the goals of a given group. That
person would have been allowed by a group to edit web pages,
commit code directly to a project gate, or help moderate a
mailing list, for example. Each user group, project, and
community may have their own set of standards for recognizing a
person as a contributor.
3. Leaders: Those who have the responsibility of leading a user
group, project or community. For example, they may have the
final say to wrap up discussions, or they may decide the
technical direction of a given project. Leaders may appoint
participants to the level of contributor. Leaders may also
appoint participants/contributors to the level of leader. Each
user group, project, and community may have their own set of
standards by which a person is recognized as a leader.
</pre>
<pre wrap=""><!---->While the "Leader" role is clearly scoped to a user group, project, or
community - it's not immediately clear to me from the definition of the
Contributor role what it's scope is. Perhaps, "That person is allowed
by a group to edit the group's web pages, commit code to the group's
gate, or help moderate its mailing lists" ?
</pre>
Here are the roles in context:
http://www.genunix.org/wiki/index.php/OGB_2008/010
Contributor will have to mean two different things -- one for
communities and one for projects. And it does not appear in User
Groups. I feel it's confusing, too, which is why I suggested
"committer" for projects since that's really about code, while
"contributor" would be fine for communities since that's more general.
But the OGB decided to make the roles in each groups the same, whereas
earlier a suggestion was made to have one term equal one definition.
Looking at the definitions out of the context of the groups is
absolutely confusing -- especially how I have presented it here in this
document. But, as others have suggested, I'll pull these sections back
out into separate documents and make clear the roles in the context of
the groups and I think it will be more clear.
Jim
--
http://blogs.sun.com/jimgris/
|
|
|
|
|
Posts:
94
From:
US
Registered:
3/9/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 8, 2008 10:02 AM
in response to: jimgris
|
|
Jim> Here's a start at a new Constitution...
First, thanks for doing this. I think it is quite well written for such a
"really rough" draft. I have some high-level feedback and some wording nits,
both of which may partially overlap with feedback already heard from others.
Jim> Create a new "bug" ...
Wording nit: s/Create/File/
Jim> Mailing list names should indicate purpose...
Agreed.
Jim> ... and have one of the following suffices:
Jim> * -dev: developer discussion
Jim> * -discuss: general discussion
Jim> * -notify: notification alias for SCM putbacks
High-level: this seems like an implementation detail, whereas the Constitution
is an architecture document.
Wording nit: "putback" is (AFAIK) a Teamware-specific term, so I would
suggest "updates" instead.
Jim> Private mailing lists may be granted in exceptional circumstances...
On the one hand, I feel that such circumstances would indeed have to be
exceptional, as in *extremely* rare, to justify having a closed list as
part of a community whose primary goal is openness. On the other hand,
given that we (the OGB) have our own private list for dealing with
confidential matters, I don't want to be hypocritical.
Jim> ... For each collective to which you substantially contribute...
Wording nit: we seemed to have switched terms from "group" to "collective".
Jim> ... You can reactivate your Membership up to 14 days after a
Jim> community wide election is announced.
Jim> ... The OGB shall provide notice to the community not less than
Jim> ten days or more than sixty days before the date of the meeting...
High-level: I think having 14 days for the one and 10 days for the other
is bad; those two values should match. Later text (7 days for nominations
and 7 days for public view) suggests that 14 is the better choice.
Jim> ... OGB members can serve for three consecutive terms.
Wording nit: s/for three/for up to three/
Jim> In the event that there are no further candidates from the prior
Jim> election, or if the vacancy is due to the removal of an OGB member,
Jim> the vacancy shall not be filled until the next OGB election.
High-level: why would the vacancy not be filled if due to removal? There
may be a case for this position, but it is not obvious to me.
Jim> This Constitution may be updated or repealed by an affirmative vote of
Jim> a majority of the Members during annual meetings
High-level: only during annual meetings? I would think a special election
would also suffice.
Jim> If the OGB is reduced in membership below the minimum of three members,
Jim> Sun Microsystems shall appoint a new board.
High-level: why appointment via Sun rather than a new election? Again, I'm
not saying this is right or wrong, just curious as to the rationale.
-- John
http://blogs.sun.com/jbeck
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
50
From:
Menlo Park
Registered:
2/16/08
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 8, 2008 11:20 AM
in response to: jbeck
|
|
John Beck wrote:
> Jim> Here's a start at a new Constitution...
>
> First, thanks for doing this. I think it is quite well written for such a
> "really rough" draft. I have some high-level feedback and some wording nits,
> both of which may partially overlap with feedback already heard from others.
>
>
> Jim> Create a new "bug" ...
>
> Wording nit: s/Create/File/
>
>
> Jim> Mailing list names should indicate purpose...
>
> Agreed.
>
> Jim> ... and have one of the following suffices:
>
> Jim> * -dev: developer discussion
> Jim> * -discuss: general discussion
> Jim> * -notify: notification alias for SCM putbacks
>
> High-level: this seems like an implementation detail, whereas the Constitution
> is an architecture document.
>
> Wording nit: "putback" is (AFAIK) a Teamware-specific term, so I would
> suggest "updates" instead.
>
>
> Jim> Private mailing lists may be granted in exceptional circumstances...
>
> On the one hand, I feel that such circumstances would indeed have to be
> exceptional, as in *extremely* rare, to justify having a closed list as
> part of a community whose primary goal is openness. On the other hand,
> given that we (the OGB) have our own private list for dealing with
> confidential matters, I don't want to be hypocritical.
>
>
> Jim> ... For each collective to which you substantially contribute...
>
> Wording nit: we seemed to have switched terms from "group" to "collective".
>
>
> Jim> ... You can reactivate your Membership up to 14 days after a
> Jim> community wide election is announced.
>
> Jim> ... The OGB shall provide notice to the community not less than
> Jim> ten days or more than sixty days before the date of the meeting...
>
> High-level: I think having 14 days for the one and 10 days for the other
> is bad; those two values should match. Later text (7 days for nominations
> and 7 days for public view) suggests that 14 is the better choice.
>
>
> Jim> ... OGB members can serve for three consecutive terms.
>
> Wording nit: s/for three/for up to three/
>
>
> Jim> In the event that there are no further candidates from the prior
> Jim> election, or if the vacancy is due to the removal of an OGB member,
> Jim> the vacancy shall not be filled until the next OGB election.
>
> High-level: why would the vacancy not be filled if due to removal? There
> may be a case for this position, but it is not obvious to me.
>
>
> Jim> This Constitution may be updated or repealed by an affirmative vote of
> Jim> a majority of the Members during annual meetings
>
> High-level: only during annual meetings? I would think a special election
> would also suffice.
>
>
> Jim> If the OGB is reduced in membership below the minimum of three members,
> Jim> Sun Microsystems shall appoint a new board.
>
> High-level: why appointment via Sun rather than a new election? Again, I'm
> not saying this is right or wrong, just curious as to the rationale.
>
>
Didn't realize this was in the constitution. Currently, unless I'm
mistaken, if someone "leaves" the board for whatever reason, the next
person from the previous election results would take over in vote
totals, is that correct? Would we continue that process until we ran
out of candidates and then hit this? If so, a "re election" seems more
appropriate, I'd be really surprised if we hit that case.
> -- John
>
> http://blogs.sun.com/jbeck
> _______________________________________________
> ogb-discuss mailing list
> ogb-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
>
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
6,807
From:
US
Registered:
3/9/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 8, 2008 11:34 AM
in response to: tjcramer
|
|
Tim Cramer writes:
> > High-level: why appointment via Sun rather than a new election? Again, I'm
> > not saying this is right or wrong, just curious as to the rationale.
> >
> >
> Didn't realize this was in the constitution. Currently, unless I'm
> mistaken, if someone "leaves" the board for whatever reason, the next
> person from the previous election results would take over in vote
> totals, is that correct? Would we continue that process until we ran
> out of candidates and then hit this? If so, a "re election" seems more
> appropriate, I'd be really surprised if we hit that case.
That'd be sections 6.4 and 6.5.
6.4 says that if the OGB members all quit or die at once, then there's
a special election. (Article X gives the authority to call that
election and declare the results to Sun, but doesn't really describe
how "Sun" should take that up.)
6.5 says that if an OGB member is *removed* (rather than just quits),
then the vacancy is cannot be filled until the next election. I guess
if the Members held a vote of "no confidence" in each member one at a
time, you'd eventually end up with a too-small OGB, and trip over
Article X.
The previous election results matter only if someone quits or dies in
office, and then only if the required minimum are left in order to
have an official OGB meeting to handle the problem.
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 15, 2008 1:56 AM
in response to: carlsonj
|
|
Here's another cut at the Constitution.
Still not there, but making some progress. I think I got most of the
comments on the thread thus far. If you
commented on parts that I took out (project creation process or
membership process), we can update those separately since those
documents will have to be edited. If I missed other comments, just
flag me.
This document is now based only in part on the previous Constitution.
What text I kept from the Constitution I edited heavily and in some
cases changed intent (such as the Disputes section). We can discuss
these changes during this process. Generally, I cut out a great deal of
information, so it's not helpful to do a line by line analysis. We as a
community do not follow all of the Constitution as written, so I'd like
to see us consider starting with a much shorter document that doesn't
necessarily consider every possible situation. Then we can build up
from there if needed.
Here's a rough review of changes:
Article 1. Name: Removed. I'm not sure how to handle this because this
section refers to the Charter, and we have to consider the Charter in
this as well. I never really saw a connection between the Charter and
Constitution, so my view is that we don't even need a Charter and the
Constitution should stand on its own. But we can deal with that in
subsequent drafts.
Article 2. Purpose: Edited parts of this into other sections and
removed other parts.
Article 3. Structure, Participation, and Roles: Replaced with new
roles/groups content approved by the OGB. Elevated Disputes to its own
section. Changed #4 of Disputes to say a suspended member may /not/
vote. This is for discussion.
Article 4. Membership: Replaced with the new membership approved by the
OGB.
Article 5. Meetings of Members: Edited.
Article6. Governing Board: Edited.
Article 7 Community Groups: Removed. The new structure is flat and
doesn't require the OGB to specify in detail how groups operate. Also,
some content in this section is covered in the new group creation
process.
Article 8. Community Group Voting Procedures: Removed. The OGB may very
well decide to publish some suggested ways to run a group (voting,
management, etc), but it's not the role of the OGB to get down to this
level of detail for each group.
Article 9 Amendments: Edited
Article 10. Dissolution: Edited
==============================================
The OpenSolaris Constitution
Overview
This
Constitution outlines the basic structure and operation of the
OpenSolaris community and the OpenSolaris Governing Board (OGB).
Previous versions of the Constitution can be found at the OGB's
website.
Structure
Groups. The OpenSolaris
community is structured as a distributed organization of participants
in
which Members are given the right to vote on community-wide issues,
the most important of which is to elect the OGB. The OGB, in turn,
delegates the organization, operations, and decision-making processes
for OpenSolaris activities to participants running their own groups.
>From a governance perspective, all groups are considered equal in
status, there are no hierarchal relationships between groups, and the
number of groups within a given category can vary greatly. There are
three operational categories of groups and one non-operational group:
- Communities:
Social groups gathered around issues or
technologies.
- Projects:
Development groups gathered around code repositories
and integration tools.
- User Groups:
Groups of users gathered around issues or
technologies in a specific geography.
- Electorate:
A group that holds voting Members of the overall OpenSolaris Community.
This group is not considered operational in that its Members
participate in the activities of the other three groups.
The OGB specifies a single process for creating, changing, archiving,
and reactivating all groups. The document outlining those procedures
can be found at the OGB's website, and it may be updated as the
community's needs evolve.
Roles. There are three
operational roles in
the OpenSolaris community:
- Participants:
Those registered on opensolaris.org are
eligible to be participants in a Community, Project, or User Group.
- Contributors:
Those recognized as having
substantially helped with the goals of a given group. That person may
be given the right to edit web pages, commit code, or help moderate
mailing lists, for example.
- Leaders: Those
responsible for leading a Community, Project, or User Group. Leaders
may decide the technical direction of a
given Project, for example. Leaders may also appoint Participants to be
Contributors and Leaders.
All of the groups may have have different standards for recognizing
people as Participants, Contributors, or Leaders within their
respective groups. However, if a participate wants to become a Member
of the OpenSolaris community and be engaged in community-wide issues,
then he or she has to apply for Membership at the OGB.
Membership
Membership: Participants,
Contributors,
and Leaders from Communities, Projects, and User Groups may become
associated with the Electorate group as voting Members of the
OpenSolaris community. Only those who have substantially and verifiably
contributed
to a group may apply for Membership. Qualification
for Membership is for life; however, Memberships must be renewed every
two years.
The OGB specifies a single process for membership applications. The
document outlining those procedures can be found at the OGB's website,
and it may be updated as the community's needs evolve.
Meetings of Members
Meetings. A Meeting
of the Members will be held annually to elect the OGB and ratify
any proposed Constitutional changes. The OGB will notify the community
not less than ten days or more than sixty days before the meeting with
the necessary logistics. One-third of the Members,
represented in person or by proxy, constitutes a
quorum, and the affirmative
vote of a majority of the Members shall be
the act of the Members. The OGB can call for Special Meetings of the
Members outside the Annual Meetings, and Members can also call for
Special Meetings if more than 10 percent of the Membership agrees.
Voting. Members are
entitled to one vote on each matter
submitted at a Meeting of the Members. A Member may vote in
person, by proxy, or, when a vote is
conducted by electronic ballot, by submitting a completed ballot to the
voting mechanism.
Proxies. Every Member may
authorize another person to act on his or her behalf as a Member by
Proxy. Every proxy must be signed by the Member
and delivered to the Secretary. Proxies are valid for up to one year.
All proxies
shall be revocable.
Minutes. Minutes of any Meeting
of the Members shall be
posted in a public forum within thirty days.
Governing Board
OGB. The OGB consists of a
minimum of three and a
maximum of seven people who provide guidance to the OpenSolaris
community, maintain the community's Constitution, run elections, and to
help
mediate disputes. The OGB values transparency, prefers delegation and
empowerment, and strives to be enablers, facilitators and
behind-the-scenes troubleshooters. OGB members, upon change of
corporate
affiliation or other
interests related to OpenSolaris, must notify the Membership of their
new status.
Election and Term. At the
annual meeting of Members, the Members shall elect OGB Members to
hold office starting the first day of the
calendar month following the election and continuing until the first
day of the calendar month following the next annual meeting.
Each OGB member shall hold office for the term for which he or she is
elected, until his or her successor us elected, or until
his or her earlier resignation, removal, or death. OGB members can
serve for up to three consecutive terms.
Candidates and Voting.
Candidates for
election to the OGB must be nominated by a current
Member. Nominations shall be open seven days prior
to ballot completion. An election ballot must be complete and
publicly viewable seven days prior to the start of
voting. Once voting has started, the voting shall remain open for seven
days. Candidates for election must publish a list of their
commercial
affiliations or other interests related to OpenSolaris, so
voting Members can understand the context from which they would act on
the OGB. Candidates who do not publish such a statement shall not be
eligible for election. The Secretary of the OGB
shall maintain a public register of OGB Members' affiliations.
Voting. The OGB election shall
use the balloting method known as Single
Transferable Vote with the Meek algorithm.
Resignations,
Removals, and Vacancies. An OGB Member may resign or be removed
by an affirmative vote of two-thirds of
the Members. If the entire OGB resigns or if a majority of the
community
expresses "no confidence" in an affirmative vote, then a special
election
will be held within thirty days. In
the event of a
resignation, removal, or death, the OGB shall review the ballot results
of the
previous election and appoint the next available candidate to fill the
vacancy. If there are no further candidates from the
prior election, the vacancy shall not be filled until the next OGB
election.
Quorum. A majority
of the OGB members in office
shall constitute a quorum. The vote of
a majority of the OGB members present at a meeting at which a quorum is
present shall be the act of the OGB.
Meetings. OGB meetings should
be held at least once a quarter.
Meetings may be
held in person or via teleconference, IRC, or equivalent
medium for shared communication. OGB meetings are open, but
occasionally the OGB may need to discuss confidential items in a closed
session. Any decisions resulting from a closed session must be approved
in an open meeting.
Officers. The officers of the
OGB shall consist of a Chair, a
Vice-Chair, and a Secretary, each of whom shall be appointed by the
OGB.
The offices of Chair and Vice Chair must be held by OGB members, but
the Secretary need not be an OGB member. The officers shall have the
following duties:
- The Chair shall preside at all Meetings of the Members and of the
OGB.
- The Vice Chair shall, in the absence or the Chair, perform the
duties of the Chair.
- The Secretary shall publish records of
all public meetings and maintain Membership records of the OpenSolaris
community.
Board Committees. The OGB may
create board committees, each consisting of at least one OGB member and
composed of participants appointed by the OGB.
Dispute Resolution
Disputes. Disputes should be
resolved within groups according to
their
normal decision-making procedures. If a dispute can not be resolved in
a group or spreads into to the
OpenSolaris community generally,
then the participants may ask the OGB to help mediate a reasonable
solution. The OGB will consider disputes on a case-by-case basis.
Suspensions. If outright abuse
is reported to the
OGB, the situation will be reviewed in the following way:
- The OGB will notify the individual that his or her participation
in the community is under review and that the review will
be completed within thirty days. The review should occur in a closed
session and remain private unless an action is made to suspend the
participant.
- The OGB may temporarily remove the participant's write
access to community infrastructure until the review is
complete.
- When the review is completed, the OGB may suspend the
participant's write access to community infrastructure
for up to six months. If the participant has previously been suspended,
the OGB may recommend expulsion.
- A suspended member may not attend or vote at Annual Meetings or
Special Meetings.
Expulsion.
The OGB may expel a participant by an affirmative vote of a two-thirds
majority of the Members. Expulsion involves the removal of all grants
of Membership and the removal of the participant's write
access to community infrastructure until a
subsequent act of the Members revokes the expulsion.
Amendments
The Constitution may be changed by an affirmative vote if a majority of
the Members during Annual Meetings or Special Meetings.
Dissolution
If the OGB is reduced in membership below three members,
Sun Microsystems will appoint a new board and community operations will
continue under the Constitution.
==============================================
Jim
--
http://blogs.sun.com/jimgris/
|
|
|
|
|
Posts:
6,807
From:
US
Registered:
3/9/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 15, 2008 6:19 AM
in response to: jimgris
|
|
Jim Grisanzio writes:
> Article 8. Community Group Voting Procedures: Removed. The OGB may very
> well decide to publish some suggested ways to run a group (voting,
> management, etc), but it's not the role of the OGB to get down to this
> level of detail for each group.
If groups can define their own arbitrary procedures (e.g., "Bob makes
all the decisions; the rest of you are peons"), then that seems to
mean that there are no standards. How can the OGB effectively mediate
any disputes that might arise?
I mostly agree with the idea of avoiding excessive detail here, and
that details can (and should) go in other day-to-day documents, but I
*do* think it's the role of the OGB to set out standard operating
practices for the groups to follow. It shouldn't be an administrative
free-for-all.
> 4. Electorate: A group that holds voting Members of the overall
> OpenSolaris Community. This group is not considered operational in
> that its Members participate in the activities of the other three
> groups.
This part isn't very clear, but I *think* the intention here is to
force each Member to participate in at least one of the other
categories of groups.
If that's not the intention, then perhaps the distinction between
"operational" and "non-operational" could be dropped. There's no
reason that someone can't be a member of both the "Electorate" group
and some other group.
> 3. Leaders: Those responsible for leading a Community, Project, or
> User Group. Leaders may decide the technical direction of a given
> Project, for example. Leaders may also appoint Participants to be
> Contributors and Leaders.
Do all groups have to have leaders? Perhaps "Projects" do, but it
seems a less obviously necessary distinction for "Communities" and
"User Groups."
It also seems a bit weird to delegate everything about how groups are
run to the groups themselves, but then define these specific types of
individual roles at the top level. Why delegate the way in which
group decisions are made, but mandate the participant roles?
> OGB. The OGB consists of a minimum of three and a maximum of seven
> people who provide guidance to the OpenSolaris community, maintain the
Can corporations and other legal persons (other than natural persons)
be members?
Normally, "legal persons" are permitted to enter into contracts like
this unless explicitly excluded. The current constitution excludes
such legal entities from acting as Members, but it seems that the new
one does not.
Is that change intentional, or are you just trying to avoid the
appearance of too much "legalese?" (If it's the latter, then I think
the loss of precision is a bigger problem than the sometimes stilted
argot of the law.)
> Resignations, Removals, and Vacancies. An OGB Member may resign or be
> removed by an affirmative vote of two-thirds of the Members. If the
> entire OGB resigns or if a majority of the community expresses "no
> confidence" in an affirmative vote, then a special election will be held
> within thirty days. In the event of a resignation, removal, or death,
> the OGB shall review the ballot results of the previous election and
> appoint the next available candidate to fill the vacancy. If there are
> no further candidates from the prior election, the vacancy shall not be
> filled until the next OGB election.
This part documents a procedural change, but I'm not sure if it's
intentional. In the current constitution, removal does *not* result
in pulling a player up from the minors. Is it the OGB's intent to
change this rule?
I think it'd be good to talk with the folks who wrote the original
constitution about the rationale for that exclusion. It doesn't look
to me like it was accidental at all, and I think it has a purpose.
I'm not one of those folks, so I don't have special insight here, but
I think that one logical purpose for it would be to diminish the
ability of outside groups to call "no confidence" votes in order to
play games with the election result. (Just a guess, though.)
> If the OGB is reduced in membership below three members, Sun
> Microsystems will appoint a new board and community operations will
> continue under the Constitution.
This looks like a big change to me. The current constitution does
*not* allow Sun to appoint board members under any circumstances.
Instead, it requires a vote of the Members to replace the board.
Why is this change needed?
Jim Grisanzio writes:
> > The previous election results matter only if someone quits or dies in
> > office, and then only if the required minimum are left in order to
> > have an official OGB meeting to handle the problem
> >
>
> I tried to combine some of these sections so they are not spread out.
> Also, if Sun had to appoint a new board, the obvious choice to do it
> would be the exec representative (currently T. Cramer). But then things
> can continue as per the constitution and the next election comes around
> as scheduled.
That isn't so obvious to me, particularly as the current constitution
specifies that only the Members can elect a new OGB, not Sun.
Why would any Sun executive be needed to name new OGB members?
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 15, 2008 9:16 AM
in response to: carlsonj
|
|
James Carlson wrote:
> Jim Grisanzio writes:
>
>> Article 8. Community Group Voting Procedures: Removed. The OGB may very
>> well decide to publish some suggested ways to run a group (voting,
>> management, etc), but it's not the role of the OGB to get down to this
>> level of detail for each group.
>>
>
> If groups can define their own arbitrary procedures (e.g., "Bob makes
> all the decisions; the rest of you are peons"), then that seems to
> mean that there are no standards.
Well, as a practical matter I'm willing to trust that most groups will
put together reasonable procedures to govern themselves. With projects,
the development methodology and lead engineers will provide the
structure. With user groups, it's a local issue that generally occurs
very far from the main community (and across language/culture barriers)
so I can't imagine the OGB having much to say about their operations
since most UGs value their independence. And Communities can be as
simple as a SIG with a list and some web pages or more complex and
associate themselves with Projects (as they do now). Those are three
rather different groups. I'm not sure writing standards for them is needed.
> How can the OGB effectively mediate
> any disputes that might arise?
>
I think we'll have to cross that bridge when we come to it. Off hand, I
can't think of a dispute that has been brought to the OGB from a Project
or Community that needed mediation.
> I mostly agree with the idea of avoiding excessive detail here, and
> that details can (and should) go in other day-to-day documents, but I
> *do* think it's the role of the OGB to set out standard operating
> practices for the groups to follow. It shouldn't be an administrative
> free-for-all.
>
Currently it's already a free-for-all in the sense that the OGB
specifies rules in the Constitution that it won't or can't enforce. One
of the reasons I have been arguing taking that text out is that I doubt
it's needed. Sure, some Communities are obviously well run and others
less so, but I'm ok with that. And for the most part, I don't really see
people complaining about this. Also, I've never seen the OGB as a
centralizing body because I never felt it had the scope to enforce
things actively. I think practice demonstrates that. But I get your
point about at least providing enough structure/standards so things can
function at a minimum level, though. We'll just have to find that balance.
>> 4. Electorate: A group that holds voting Members of the overall
>> OpenSolaris Community. This group is not considered operational in
>> that its Members participate in the activities of the other three
>> groups.
>>
>
> This part isn't very clear, but I *think* the intention here is to
> force each Member to participate in at least one of the other
> categories of groups.
>
> If that's not the intention, then perhaps the distinction between
> "operational" and "non-operational" could be dropped. There's no
> reason that someone can't be a member of both the "Electorate" group
> and some other group.
>
Good point.
After I wrote that I was thinking that we ought to not only drop the
notion of "operational" and "non-operational" from the text (I added it
in this draft) but also drop even mentioning the fourth group
(Electorate) in the context of the other three. In other words, we
really have three collective categories of groups that do things:
Communities, Projects, and User Groups. Electorate is really a back end
term to hold Members that result from the other three, so that term may
be less confusing if it's moved into the Membership section. That makes
it easier to just remove the operational/non-operational stuff. This is
an effort to separate operations from Membership. I realize that some
people (probably most, actually) believe that Membership is a higher
status than some of the other roles, but I'm not at all in that camp.
That's why I like separating it out. I'll have to work on this section more.
>> 3. Leaders: Those responsible for leading a Community, Project, or
>> User Group. Leaders may decide the technical direction of a given
>> Project, for example. Leaders may also appoint Participants to be
>> Contributors and Leaders.
>>
>
> Do all groups have to have leaders? Perhaps "Projects" do, but it
> seems a less obviously necessary distinction for "Communities" and
> "User Groups."
>
> It also seems a bit weird to delegate everything about how groups are
> run to the groups themselves, but then define these specific types of
> individual roles at the top level. Why delegate the way in which
> group decisions are made, but mandate the participant roles?
>
I think all groups need a leader as a point of contact. We need someone
to talk to to get groups set up and deal with infrastructure issues,
etc. There has to be some level of communication back and forth. And we
have to specify certain roles so we can build them into the webapp. But
other than that, I'm happy for groups to run themselves. And if they
never want to be Members and come to the OGB for that part, than that's
fine too.
>> OGB. The OGB consists of a minimum of three and a maximum of seven
>> people who provide guidance to the OpenSolaris community, maintain the
>>
>
> Can corporations and other legal persons (other than natural persons)
> be members?
>
My own view on this is no.
> Normally, "legal persons" are permitted to enter into contracts like
> this unless explicitly excluded. The current constitution excludes
> such legal entities from acting as Members, but it seems that the new
> one does not.
>
> Is that change intentional, or are you just trying to avoid the
> appearance of too much "legalese?" (If it's the latter, then I think
> the loss of precision is a bigger problem than the sometimes stilted
> argot of the law.)
>
I took out every instance of legalese (or what I thought was legalese,
anyway) I could find. We can fix it.
>> Resignations, Removals, and Vacancies. An OGB Member may resign or be
>> removed by an affirmative vote of two-thirds of the Members. If the
>> entire OGB resigns or if a majority of the community expresses "no
>> confidence" in an affirmative vote, then a special election will be held
>> within thirty days. In the event of a resignation, removal, or death,
>> the OGB shall review the ballot results of the previous election and
>> appoint the next available candidate to fill the vacancy. If there are
>> no further candidates from the prior election, the vacancy shall not be
>> filled until the next OGB election.
>>
>
> This part documents a procedural change, but I'm not sure if it's
> intentional. In the current constitution, removal does *not* result
> in pulling a player up from the minors. Is it the OGB's intent to
> change this rule?
>
I don't see why a removal should not be replaced. I changed it in this
second draft.
> I think it'd be good to talk with the folks who wrote the original
> constitution about the rationale for that exclusion. It doesn't look
> to me like it was accidental at all, and I think it has a purpose.
>
That's fine. I can't remember the reasoning, but I'm sure someone will
offer an opinion and refresh our memories. If it's necessary, we can put
it back easily enough.
> I'm not one of those folks, so I don't have special insight here, but
> I think that one logical purpose for it would be to diminish the
> ability of outside groups to call "no confidence" votes in order to
> play games with the election result. (Just a guess, though.)
>
>
>> If the OGB is reduced in membership below three members, Sun
>> Microsystems will appoint a new board and community operations will
>> continue under the Constitution.
>>
>
> This looks like a big change to me. The current constitution does
> *not* allow Sun to appoint board members under any circumstances.
> Instead, it requires a vote of the Members to replace the board.
>
> Why is this change needed?
>
Article 10 currently says that custody of the community goes back to Sun
if the OGB goes under 3 members. It's not at all clear what that means,
especially when you read some of the language in Article 6. It almost
seems like Article 10 goes back to a bootstrap phase where someone would
have to repopulate the roles to keep things going from a governance
perspective. That's all I'm saying here. Someone has to step in and do
something in this case. If the community can elect a new OGB without an
existing OGB (or Sun) running the election than fine, we don't need Sun
to appoint a board until the next election. It's not a big deal, really.
I think the current Constitution is unclear in this case (albeit an
extreme case).
Jim
--
http://blogs.sun.com/jimgris/
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
6,807
From:
US
Registered:
3/9/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 15, 2008 10:46 AM
in response to: jimgris
|
|
Jim Grisanzio writes:
> James Carlson wrote:
> > If groups can define their own arbitrary procedures (e.g., "Bob makes
> > all the decisions; the rest of you are peons"), then that seems to
> > mean that there are no standards.
>
> Well, as a practical matter I'm willing to trust that most groups will
> put together reasonable procedures to govern themselves. With projects,
> the development methodology and lead engineers will provide the
> structure. With user groups, it's a local issue that generally occurs
> very far from the main community (and across language/culture barriers)
> so I can't imagine the OGB having much to say about their operations
> since most UGs value their independence. And Communities can be as
> simple as a SIG with a list and some web pages or more complex and
> associate themselves with Projects (as they do now). Those are three
> rather different groups. I'm not sure writing standards for them is needed.
By "standards," I mean something perhaps like this:
If your group is defined in such a way that it makes decisions
(not all groups do; some are merely social conventions), then
it must have a documented decision-making process. This needs
to exist so that the OGB can mediate any disputes that may
arise. If your group does not have a documented process and a
dispute occurs, the OGB will resolve it in any manner it sees
fit.
If you hold votes in order to resolve issues, then you are
encouraged to use the procedure documented for community-wide
voting. The web site infrastructure provides automated tools
for conducting such polling at <x>.
At least when a given procedure is used, it would help to have
uniformity rather than chaos. I don't mind seeing some groups decide
that a single person makes all the decisions, while others decide that
a group does it, and still others stay away from decision-making
entirely, but I do mind having arbitrarily different processes for the
same thing in different places. It's confusing, and serves no good
purpose other than to make it difficult for members to participate in
multiple groups, and thus for groups to cooperate with each other.
> > How can the OGB effectively mediate
> > any disputes that might arise?
> >
>
> I think we'll have to cross that bridge when we come to it. Off hand, I
> can't think of a dispute that has been brought to the OGB from a Project
> or Community that needed mediation.
I don't think that's the point. The terms in the constitution form an
agreement of how we're going to handle likely cases that haven't
happened yet. Simply saying "whatever" shouldn't be one of the
answers.
In the last OGB, we did handle some disputes, so I'm not sure that's a
viable position anyway.
> > It also seems a bit weird to delegate everything about how groups are
> > run to the groups themselves, but then define these specific types of
> > individual roles at the top level. Why delegate the way in which
> > group decisions are made, but mandate the participant roles?
> >
>
> I think all groups need a leader as a point of contact. We need someone
> to talk to to get groups set up and deal with infrastructure issues,
> etc. There has to be some level of communication back and forth. And we
> have to specify certain roles so we can build them into the webapp. But
> other than that, I'm happy for groups to run themselves. And if they
> never want to be Members and come to the OGB for that part, than that's
> fine too.
The previous structure had a Liaison to make it clear that the person
set up as a point of contact needn't actually be in any position of
leadership or decision-making for the group, but perhaps that's now
seen as just an unnecessary distinction.
However, I'm not sure that every group needs a point of contact. Few
(if any) contacts are initiated by the OGB itself to any group, and
when they are, they're generally directed to a group's mailing list
rather than to an individual. The flow usually goes the other
direction.
This still falls under the same strange set of boundaries for me. I
don't understand why the OGB is setting out roles to play in such
great detail, while explicitly avoiding the much more important
question of how groups can govern themselves. I would have expected
that group governance and roles go hand-in-hand; they're part of the
same design.
If the OpenSolaris Governing Board doesn't decide issues of
governance, what does it do?
> >> OGB. The OGB consists of a minimum of three and a maximum of seven
> >> people who provide guidance to the OpenSolaris community, maintain the
> >>
> >
> > Can corporations and other legal persons (other than natural persons)
> > be members?
> >
>
> My own view on this is no.
In that case, "natural persons" in the original text was correct, and
the new text is not right.
> > I think it'd be good to talk with the folks who wrote the original
> > constitution about the rationale for that exclusion. It doesn't look
> > to me like it was accidental at all, and I think it has a purpose.
> >
>
> That's fine. I can't remember the reasoning, but I'm sure someone will
> offer an opinion and refresh our memories. If it's necessary, we can put
> it back easily enough.
As I'm a Member who will eventually be voting on the results, I want
to see that there's a rationale for every *change* that's made. If
there isn't one, then please don't make it, because I won't vote in
favor of capricious change.
> >> If the OGB is reduced in membership below three members, Sun
> >> Microsystems will appoint a new board and community operations will
> >> continue under the Constitution.
> >>
> >
> > This looks like a big change to me. The current constitution does
> > *not* allow Sun to appoint board members under any circumstances.
> > Instead, it requires a vote of the Members to replace the board.
> >
> > Why is this change needed?
> >
>
> Article 10 currently says that custody of the community goes back to Sun
> if the OGB goes under 3 members. It's not at all clear what that means,
> especially when you read some of the language in Article 6.
Both sections of the constitution are clear: only OpenSolaris Members
can vote for OGB members. Period.
That was actually a bit of hand-wavy exception at the start of the
whole OGB, because we were voting for the constitution itself and for
the OGB, and there was no provision for either to go first.
The old CAB was Sun-picked, but not the OGB.
> It almost
> seems like Article 10 goes back to a bootstrap phase where someone would
> have to repopulate the roles to keep things going from a governance
> perspective.
That "someone" is clear: the Members themselves must vote in a new
OGB. Nobody else can.
> That's all I'm saying here.
I disagree. The new text explicitly says that Sun can appoint OGB
members without a vote. That's a substantial change.
> Someone has to step in and do
> something in this case. If the community can elect a new OGB without an
> existing OGB (or Sun) running the election than fine, we don't need Sun
> to appoint a board until the next election. It's not a big deal, really.
> I think the current Constitution is unclear in this case (albeit an
> extreme case).
I think it's quite clear on OGB membership coming only from the votes
of OpenSolaris Members.
If you'd like to specify additional details for how Sun may call for
that new election in the unlikely event that the OGB resigns or is
removed, I think that's probably fine, but I object to adding a new
mechanism that allows Sun to appoint any members without a vote.
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Stephen Lau
stevel@opensolaris.org
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 15, 2008 11:23 AM
in response to: carlsonj
|
|
On 10/15/08 6:19 AM, James Carlson wrote:
> Jim Grisanzio writes:
>
>> Article 8. Community Group Voting Procedures: Removed. The OGB may very
>> well decide to publish some suggested ways to run a group (voting,
>> management, etc), but it's not the role of the OGB to get down to this
>> level of detail for each group.
>>
>
> If groups can define their own arbitrary procedures (e.g., "Bob makes
> all the decisions; the rest of you are peons"), then that seems to
> mean that there are no standards. How can the OGB effectively mediate
> any disputes that might arise?
>
> I mostly agree with the idea of avoiding excessive detail here, and
> that details can (and should) go in other day-to-day documents, but I
> *do* think it's the role of the OGB to set out standard operating
> practices for the groups to follow. It shouldn't be an administrative
> free-for-all.
>
I think minimum operating practices would be good, but I want to avoid
making certain assumptions about how a group should operate. A user
group != documentation community != ON, and should set its own
procedures accordingly.
Additionally, letting groups decide their own ways of running the group
makes for better scale rather than the OGB trying to set standard
procedures to apply to both groups as large as ON, and groups as small
as our San Francisco OSUG.
(I'm fairly certain SFOSUG has a minimum operating procedure that every
member must have at least two beers (except Danek) per meeting - and I'm
not so sure that applies to ON :-P)
>> 3. Leaders: Those responsible for leading a Community, Project, or
>> User Group. Leaders may decide the technical direction of a given
>> Project, for example. Leaders may also appoint Participants to be
>> Contributors and Leaders.
>>
>
> Do all groups have to have leaders? Perhaps "Projects" do, but it
> seems a less obviously necessary distinction for "Communities" and
> "User Groups."
>
Good point.
cheers,
steve
--
stephen lau | stevel at opensolaris dot org | www.whacked.net
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
6,807
From:
US
Registered:
3/9/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 15, 2008 11:35 AM
in response to: Stephen Lau
|
|
Stephen Lau writes:
> On 10/15/08 6:19 AM, James Carlson wrote:
> > I mostly agree with the idea of avoiding excessive detail here, and
> > that details can (and should) go in other day-to-day documents, but I
> > *do* think it's the role of the OGB to set out standard operating
> > practices for the groups to follow. It shouldn't be an administrative
> > free-for-all.
> >
> I think minimum operating practices would be good, but I want to avoid
> making certain assumptions about how a group should operate. A user
> group != documentation community != ON, and should set its own
> procedures accordingly.
I agree with that part.
> Additionally, letting groups decide their own ways of running the group
> makes for better scale rather than the OGB trying to set standard
> procedures to apply to both groups as large as ON, and groups as small
> as our San Francisco OSUG.
Where "running the group" means details such as who evaluates an RTI
and how that's done (for ON), I agree. That can and should be
delegated and not specified by the OGB.
When it comes to common standards, though, such as how votes (if any)
are held, or how the various OGB-defined roles are used, I think there
ought to be common practices across groups. It's ok if that's not in
the constitution itself, and is instead in some OGB-sponsored "how to
do the group thing" document, but I don't think it ought to be
delegated entirely.
Delegating this completely means that new people approaching
OpenSolaris can't count on a consistent set of processes or roles in
each group (thus setting us up for personal conflicts), and it makes
cooperation between groups (required for most non-trivial projects)
much more difficult, and it means that we can't reasonably set up
common infrastructure for all to use. It seems to have no benefits
whatsover; it's an unnecessary amount of rope.
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
785
From:
FR
Registered:
9/1/06
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 16, 2008 8:30 AM
in response to: carlsonj
|
|
Le 15 oct. 08 à 20:35, James Carlson a écrit :
> Stephen Lau writes:
>> Additionally, letting groups decide their own ways of running the
>> group
>> makes for better scale rather than the OGB trying to set standard
>> procedures to apply to both groups as large as ON, and groups as
>> small
>> as our San Francisco OSUG.
>
> Where "running the group" means details such as who evaluates an RTI
> and how that's done (for ON), I agree. That can and should be
> delegated and not specified by the OGB.
>
> When it comes to common standards, though, such as how votes (if any)
> are held, or how the various OGB-defined roles are used, I think there
> ought to be common practices across groups. It's ok if that's not in
> the constitution itself, and is instead in some OGB-sponsored "how to
> do the group thing" document, but I don't think it ought to be
> delegated entirely.
James is completly right.
User groups have to be considered as important people in the new
constitution.
OpenSource is made by contributors. Contribution could be in term of
money, but in most case the "contributor" is somebody who is giving
his time to improve/evangelize/etc.
Our members are giving time and money to go forward. Do they have any
chance to vote for OGB or any other decisions which modifies the
OpenSolaris way ?
I'm sure you'd answer yes to this last question. It implies the
constitution writes down some standards about how we run our groups,
or at least how members of ug could become member/contributor/whatever
of OpenSolaris government.
Without those standards, our own board may take decisions without any
references...which could be interpreted as power abuse by our members.
> Delegating this completely means that new people approaching
> OpenSolaris can't count on a consistent set of processes or roles in
> each group (thus setting us up for personal conflicts), and it makes
> cooperation between groups (required for most non-trivial projects)
> much more difficult, and it means that we can't reasonably set up
> common infrastructure for all to use. It seems to have no benefits
> whatsover; it's an unnecessary amount of rope.
Exactly !
Nicolas
01010101 01001110 01001001 01011000
Nicolas Dorfsman
ndo at unikservice dot com / ndo at guses dot org
Phone: +33 6 7981 4486
Skype: ndorfsman
http://www.guses.org - French Speaking (Open)Solaris User Group
http://www.solaris-fr.org - French OpenSolaris Wiki
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Moinak Ghosh
moinakg@belenix.org
|
|
|
|
Re: [ogb-discuss] [advocacy-discuss] The OpenSolaris Constitution:
(Really Rough) v2.0
Posted:
Oct 16, 2008 8:43 AM
in response to: ndorf
|
|
+1. I completely agree to the views of James and Nicolas below. Guidelines
for user groups make for a more cohesive community building approach.
Regards,
moinak.
On Thu, Oct 16, 2008 at 9:00 PM, Nicolas Dorfsman <ndo at unikservice dot eu> wrote:
>
> Le 15 oct. 08 à 20:35, James Carlson a écrit :
>
>> Stephen Lau writes:
>>> Additionally, letting groups decide their own ways of running the
>>> group
>>> makes for better scale rather than the OGB trying to set standard
>>> procedures to apply to both groups as large as ON, and groups as
>>> small
>>> as our San Francisco OSUG.
>>
>> Where "running the group" means details such as who evaluates an RTI
>> and how that's done (for ON), I agree. That can and should be
>> delegated and not specified by the OGB.
>>
>> When it comes to common standards, though, such as how votes (if any)
>> are held, or how the various OGB-defined roles are used, I think there
>> ought to be common practices across groups. It's ok if that's not in
>> the constitution itself, and is instead in some OGB-sponsored "how to
>> do the group thing" document, but I don't think it ought to be
>> delegated entirely.
>
> James is completly right.
>
> User groups have to be considered as important people in the new
> constitution.
> OpenSource is made by contributors. Contribution could be in term of
> money, but in most case the "contributor" is somebody who is giving
> his time to improve/evangelize/etc.
> Our members are giving time and money to go forward. Do they have any
> chance to vote for OGB or any other decisions which modifies the
> OpenSolaris way ?
> I'm sure you'd answer yes to this last question. It implies the
> constitution writes down some standards about how we run our groups,
> or at least how members of ug could become member/contributor/whatever
> of OpenSolaris government.
> Without those standards, our own board may take decisions without any
> references...which could be interpreted as power abuse by our members.
>
>
>> Delegating this completely means that new people approaching
>> OpenSolaris can't count on a consistent set of processes or roles in
>> each group (thus setting us up for personal conflicts), and it makes
>> cooperation between groups (required for most non-trivial projects)
>> much more difficult, and it means that we can't reasonably set up
>> common infrastructure for all to use. It seems to have no benefits
>> whatsover; it's an unnecessary amount of rope.
>
> Exactly !
>
> Nicolas
>
>
>
>
>
> 01010101 01001110 01001001 01011000
> Nicolas Dorfsman
> ndo at unikservice dot com / ndo at guses dot org
> Phone: +33 6 7981 4486
> Skype: ndorfsman
>
> http://www.guses.org - French Speaking (Open)Solaris User Group
> http://www.solaris-fr.org - French OpenSolaris Wiki
>
>
>
>
>
> _______________________________________________
> advocacy-discuss mailing list
> advocacy-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/advocacy-discuss
>
--
================================
http://www.belenix.org/
http://moinakg.wordpress.com/
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] [advocacy-discuss] The OpenSolaris Constitution:
(Really Rough) v2.0
Posted:
Oct 16, 2008 9:28 AM
in response to: ndorf
|
|
Nicolas Dorfsman wrote:
> Le 15 oct. 08 à 20:35, James Carlson a écrit :
>
>
>> Stephen Lau writes:
>>
>>> Additionally, letting groups decide their own ways of running the
>>> group
>>> makes for better scale rather than the OGB trying to set standard
>>> procedures to apply to both groups as large as ON, and groups as
>>> small
>>> as our San Francisco OSUG.
>>>
>> Where "running the group" means details such as who evaluates an RTI
>> and how that's done (for ON), I agree. That can and should be
>> delegated and not specified by the OGB.
>>
>> When it comes to common standards, though, such as how votes (if any)
>> are held, or how the various OGB-defined roles are used, I think there
>> ought to be common practices across groups. It's ok if that's not in
>> the constitution itself, and is instead in some OGB-sponsored "how to
>> do the group thing" document, but I don't think it ought to be
>> delegated entirely.
>>
This discussion reminds me that Michelle is working on some excellent
common practices documents in the website community for communities.
That may be a good home for process-oriented material like this. Or we
can just leave it in the Constitution as it is now.
> James is completly right.
>
> User groups have to be considered as important people in the new
> constitution.
>
We've been working for two years to make that a reality -- first by
making OSUGs into projects as an interim step and now by redesigning the
community governance and updating website infrastructure to make UGs
equal to Communities and Projects in a non-hierarchal system. Users are
just as important as coders. Totally agree.
Jim
--
http://blogs.sun.com/jimgris/
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Nov 3, 2008 11:51 PM
in response to: carlsonj
|
|
Ok, here's a third cut at this. It's pretty similar to the second cut
except that I added a section for group management with a brief
introduction and a place-holder pointer to a new document that can
contain processes for managing communities and projects, etc. As you'll
recall, I took out all of those processes from the current constitution
for my drafts here, but there is a desire to have the OGB offer guidance
on this issue so we are consistent across the entire community and can
properly mediate potential disputes. However, we agreed that to keep the
constitution short we'd separate the process documents. So, the
structure of this draft now looks like this:
* OpenSolaris Constitution: A brief overview of the structure of the
community and the OGB with links to three process documents:
o Group Creation Process (separate document)
o Membership Process (separate document)
o Group Management Process (separate document)
Other changes: I added back in the natural persons reference for OGB
members, I made the dissolution section consistent with the current
constitution, and I also updated the vacancy section to be more
consistent with the current constitution. Also, I put this version on
the wiki, so if anyone wants to directly edit, or if I forgot other
changes, please feel free. I haven't done any page editing/formatting
yet. It's just a copy/paste from the text below.
http://www.genunix.org/wiki/index.php/OGB_2008/010_OpenSolaris_Constitution_2009
Other references related to this discussion:
http://opensolaris.org/jive/thread.jspa?threadID=76851&tstart=0%20
http://mail.opensolaris.org/pipermail/ogb-discuss/2008-September/006066.html
http://opensolaris.org/jive/thread.jspa?threadID=77881&tstart=0
Jim
The OpenSolaris Constitution
Overview
This Constitution outlines the basic structure and operation of the
OpenSolaris community and the OpenSolaris Governing Board (OGB).
Previous versions of the Constitution can be found at the OGB's website.
http://www.opensolaris.org/os/community/ogb/governance/
Structure
Groups. The OpenSolaris community is structured as a distributed
organization of participants in which Members are given the right to
vote on community-wide issues -- the most important of which is to elect
the OGB. In turn, the OGB delegates the organization, operations, and
decision-making processes for OpenSolaris activities to participants
running their own groups. From a governance perspective, all groups are
considered equal in status, there are no hierarchal relationships
between groups, the number of groups within a given category can vary
greatly, and groups are free to create associations with other groups to
facilitate development or community building activities. There are four
categories of groups:
1. Communities: Social groups gathered around issues or technologies.
2. Projects: Development groups gathered around code repositories and
integration tools.
3. User Groups: Groups of users gathered around issues or
technologies in a specific geography.
4. Electorate: A group that holds voting Members of the overall
OpenSolaris Community.
The OGB specifies a single process for creating, changing, archiving,
and reactivating all groups. The document outlining those procedures can
be found at the OGB's website, and it may be updated as the community's
needs evolve. http://genunix2.org/wiki/index.php/OGB_2008/010_group_creation
Roles. There are three roles in the OpenSolaris community:
1. Participants: Those registered on opensolaris.org are eligible to
be participants in a Community, Project, or User Group.
2. Contributors: Those recognized as having substantially helped with
the goals of a given group. Contributors may be given the right to
edit web pages, commit code, or help moderate mailing lists, for
example.
3. Leaders: Those responsible for leading a Community, Project, or
User Group. Leaders may decide the technical direction of a given
Project, for example. Leaders may also appoint Participants to be
Contributors and Leaders.
All of the groups may have have different standards for recognizing
people as Participants, Contributors, or Leaders within their respective
groups. However, if a participate wants to become a Member of the
OpenSolaris community and be engaged in community-wide issues, then he
or she has to apply for Membership at the OGB.
Membership
Membership: Participants, Contributors, and Leaders from Communities,
Projects, and User Groups may become associated with the Electorate
group as voting Members of the OpenSolaris community. Only those who
have substantially and verifiably contributed to a group may apply for
Membership. Qualification for Membership is for life, but Memberships
must be renewed every two years. The OGB specifies a single process for
membership applications. The document outlining those procedures can be
found at the OGB's website, and it may be updated as the community's
needs evolve. http://www.genunix.org/wiki/index.php/OGB_2008/010_membership
Group Management Processes
Processes: In order to be as consistent as possible and for the purposes
mediating disputes, the OGB requests that all groups publish well
defined processes for managing their activities. These processes may
include development methodologies, voting procedures, participation
guidelines, record keeping, etc. The OGB publishes some process
documents outlining key issues that groups can use or build from. These
documents can be found at the OGB's website, and they may be updated as
the community's needs evolve
http://www.genunix.org/wiki/index.php/OGB_2008/010_Group_Management_Processes.
If there are no public process documents and if a dispute is brought to
the OGB, the board will resolve the issue at its own desertion.
Meetings of Members
Meetings. A Meeting of the Members will be held annually to elect the
OGB and ratify any proposed Constitutional changes. The OGB will notify
the community not less than ten days or more than sixty days before the
meeting with the necessary logistics. One-third of the Members,
represented in person or by proxy, constitutes a quorum, and the
affirmative vote of a majority of the Members shall be the act of the
Members. The OGB can call for Special Meetings of the Members outside
the Annual Meetings, and Members can also call for Special Meetings if
more than 10 percent of the Membership agrees.
Voting. Members are entitled to one vote on each matter submitted at a
Meeting of the Members. A Member may vote in person, by proxy, or, when
a vote is conducted by electronic ballot, by submitting a completed
ballot to the voting mechanism.
Proxies. Every Member may authorize another person to act on his or her
behalf as a Member by Proxy. Every proxy must be signed by the Member
and delivered to the Secretary. Proxies are valid for up to one year.
All proxies shall be revocable.
Minutes. Minutes of any Meeting of the Members shall be posted in a
public forum within thirty days.
Governing Board
OGB. The OGB consists of a minimum of three and a maximum of seven
natural persons who provide guidance to the OpenSolaris community,
maintain the community's Constitution, run elections, and to help
mediate disputes. The OGB values transparency, prefers delegation and
empowerment, and strives to be enablers, facilitators and
behind-the-scenes troubleshooters. OGB members, upon change of corporate
affiliation or other interests related to OpenSolaris, must notify the
Membership of their new status.
Election and Term. At the annual meeting of Members, the Members shall
elect OGB Members to hold office starting the first day of the calendar
month following the election and continuing until the first day of the
calendar month following the next annual meeting. Each OGB member shall
hold office for the term for which he or she is elected, until his or
her successor us elected, or until his or her earlier resignation,
removal, or death. OGB members can serve for up to three consecutive terms.
Candidates and Voting. Candidates for election to the OGB must be
nominated by a current Member. Nominations shall be open seven days
prior to ballot completion. An election ballot must be complete and
publicly viewable seven days prior to the start of voting. Once voting
has started, the voting shall remain open for seven days. Candidates for
election must publish a list of their commercial affiliations or other
interests related to OpenSolaris, so voting Members can understand the
context from which they would act on the OGB. Candidates who do not
publish such a statement shall not be eligible for election. The
Secretary of the OGB shall maintain a public register of OGB Members'
affiliations.
Voting. The OGB election shall use the balloting method known as Single
Transferable Vote with the Meek algorithm.
Resignations, Removals, and Vacancies. An OGB Member may resign or be
removed by an affirmative vote of two-thirds of the Members. If the
entire OGB resigns or if a majority of the community expresses no
confidence in an affirmative vote, then a special election will be held
within thirty days. In the event of a resignation or death, the OGB
shall review the ballot results of the previous election and appoint the
next available candidate to fill the vacancy. If there are no further
candidates from the prior election, or if the vacancy is due to the
removal of an OGB member, the vacancy shall not be filled until the next
OGB election.
Quorum. A majority of the OGB members in office shall constitute a
quorum. The vote of a majority of the OGB members present at a meeting
at which a quorum is present shall be the act of the OGB.
Meetings. OGB meetings should be held at least once a quarter. Meetings
may be held in person or via teleconference, IRC, or equivalent medium
for shared communication. OGB meetings are open, but occasionally the
OGB may need to discuss confidential items in a closed session. Any
decisions resulting from a closed session must be approved in an open
meeting.
Officers. The officers of the OGB shall consist of a Chair, a
Vice-Chair, and a Secretary, each of whom shall be appointed by the OGB.
The offices of Chair and Vice Chair must be held by OGB members, but the
Secretary need not be an OGB member. The officers shall have the
following duties:
* The Chair shall preside at all Meetings of the Members and of the OGB.
* The Vice Chair shall, in the absence or the Chair, perform the
duties of the Chair.
* The Secretary shall publish records of all public meetings and
maintain Membership records of the OpenSolaris community.
Board Committees. The OGB may create board committees, each consisting
of at least one OGB member and composed of participants appointed by the
OGB.
Dispute Resolution
Disputes. Disputes should be resolved within groups according to their
normal decision-making procedures. If a dispute can not be resolved in a
group or spreads into to the OpenSolaris community generally, then the
participants may ask the OGB to help mediate a reasonable solution. The
OGB will consider disputes on a case-by-case basis.
Suspensions. If outright abuse is reported to the OGB, the situation
will be reviewed in the following way:
1. The OGB will notify the individual that his or her participation
in the community is under review and that the review will be
completed within thirty days. The review should occur in a closed
session and remain private unless an action is made to suspend the
participant.
2. The OGB may temporarily remove the participant's write access to
community infrastructure until the review is complete.
3. When the review is completed, the OGB may suspend the
participant's write access to community infrastructure for up to
six months. If the participant has previously been suspended, the
OGB may recommend expulsion.
4. A suspended member may not attend or vote at Annual Meetings or
Special Meetings.
Expulsion. The OGB may expel a participant by an affirmative vote of a
two-thirds majority of the Members. Expulsion involves the removal of
all grants of Membership and the removal of the participant's write
access to community infrastructure until a subsequent act of the Members
revokes the expulsion.
Amendments
The Constitution may be changed by an affirmative vote if a majority of
the Members during Annual Meetings or Special Meetings.
Dissolution
If OGB membership is reduced to below three, custody of the OpenSolaris
community will revert to Sun Microsystems until such time as the Members
elect a new OGB.
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
1,495
From:
Registered:
5/18/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Nov 5, 2008 11:05 AM
in response to: jimgris
|
|
Jim Grisanzio wrote:
> Ok, here's a third cut at this.
> http://www.genunix.org/wiki/index.php/OGB_2008/010_OpenSolaris_Constitution_2009
I updated the wiki formatting (headings and lists) and fixed a typo or
two there.
Other comments below:
> The OpenSolaris Constitution
> Roles. There are three roles in the OpenSolaris community:
> All of the groups may have have different standards for recognizing
> people as Participants, Contributors, or Leaders within their respective
> groups. However, if a participate wants to become a Member of the
> OpenSolaris community and be engaged in community-wide issues, then he
> or she has to apply for Membership at the OGB.
I thought we had a lot of discussion and agreement that we wanted
there to be /some/ common expectations here rather than leaving it
wide open and unspecified. Something not too hot and not too cold,
but just right, as Goldilocks said.
This would be one of those non-constitutional procedures things that
might say something like "Contributers are expected to have
contributed something substantial to their group; the specifics of
what that means is expected to vary a lot on a per-group-type basis
and a little between groups of the same type. A minimal baseline for
each group type follows...".
>
>
> Membership
>
> Membership: Participants, Contributors, and Leaders from Communities,
> Projects, and User Groups may become associated with the Electorate
> group as voting Members of the OpenSolaris community.
Uhm, as you go on to say:
> ... Only those who
> have substantially and verifiably contributed to a group may apply for
> Membership.
By definition, those aren't Participants. The list on the first line
should only say Contributors and Leaders.
>
> Group Management Processes
>
> Processes: In order to be as consistent as possible and for the purposes
> mediating disputes, the OGB requests that all groups publish well
> defined processes for managing their activities.
What happens if they don't? Who reviews them to determine whether or
not they are "well defined" (or even "not malicious garbage"?)
> If there are no public process documents and if a dispute is brought to
> the OGB, the board will resolve the issue at its own desertion.
This says groups only need such procedures if there is a dispute. To
me, this is exactly the worst time to try and invent/interpret such
procedures. Maybe the group /creation/ process needs to somehow cause
those procedures/documents to be created...
> Meetings of Members
>... One-third of the Members,
> represented in person or by proxy, constitutes a quorum,
> Proxies. Every Member may authorize another person to act on his or her
> behalf as a Member by Proxy. Every proxy must be signed by the Member
> and delivered to the Secretary. Proxies are valid for up to one year.
> All proxies shall be revocable.
An alternative that would keep us out of the eternal "quest for
quorum" that happens every year would be to adopt some sort of
"default proxy" mechanism like the following:
We will have a meeting on <date> where votes will be taken
on the following topics (...). You can attend in person,
or assign your proxy to another. If you do neither (and
you can at any time), your proxy will by default be assigned
to the board to be voted as follows:
Count for Quorum
Abstain on all votes (or whatever)
> Governing Board
>
> OGB. The OGB consists of a minimum of three and a maximum of seven
> natural persons who provide guidance to the OpenSolaris community,
How does the OGB provide guidance? What avenues and mechanisms exist
for this to happen?
> OGB members, upon change of corporate
> affiliation or other interests related to OpenSolaris, must notify the
> Membership of their new status.
TODO: Need pointer to a procedure that articulates the details...
> ... starting the first day of the calendar
> month following the election and continuing until the first day of the
Shouldn't this be:
... until the *last* day ...
> calendar month following the next annual meeting. Each OGB member shall
> hold office for the term for which he or she is elected, until his or
> her successor us elected, or until his or her earlier resignation,
> removal, or death. OGB members can serve for up to three consecutive terms.
Add:
There is no limit on the number of non-consecutive terms a
member can serve.
>
> Candidates and Voting. Candidates for election to the OGB must be
> nominated by a current Member.
Is that an "OGB Member" or an "Electorate Member"?
Are we dropping the "and be registered as an OpenSolaris Participant"
part intentionally?
> Nominations shall be open seven days
I like the current wording that gives more leway:
Nominations shall be open for a minimum of
seven (7) days prior to ballot completion.
> prior to ballot completion. An election ballot must be complete and
> publicly viewable seven days prior to the start of voting. Once voting
Same: Add "at least".
> has started, the voting shall remain open for seven days. Candidates for
and again: "at least".
> Resignations, Removals, and Vacancies. An OGB Member may resign or be
> removed by an affirmative vote of two-thirds of the Members.
Again, is this an "OGB Member" or an "Electorate Member"?
> If the
> entire OGB resigns
This conflicts with the last "Dissolution" section below...
> or if a majority of the community expresses no
> confidence in an affirmative vote,
Phrasing nit: if the community votes to remove the members of
the current board through a vote of no confidence,
> Meetings. OGB meetings should be held at least once a quarter. Meetings
> may be held in person or via teleconference, IRC, or equivalent medium
> for shared communication. OGB meetings are open, but occasionally the
> OGB may need to discuss confidential items in a closed session. Any
> decisions resulting from a closed session must be approved in an open
> meeting.
Should link to http://www.genunix.org/wiki/index.php/OGB_2008/007
> Dispute Resolution
>
> Disputes. Disputes should be resolved within groups according to their
> normal decision-making procedures. If a dispute can not be resolved in a
s/normal/documented/
> group or spreads into to the OpenSolaris community generally, then the
> participants may ask the OGB to help mediate a reasonable solution. The
Can anyone other than the direct participants in a dispute involve
the OGB? Can the OGB involve itself?
> Dissolution
>
> If OGB membership is reduced to below three, custody of the OpenSolaris
> community will revert to Sun Microsystems until such time as the Members
> elect a new OGB.
-John
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Nov 10, 2008 5:50 AM
in response to: plocher
|
|
John Plocher wrote:
> Jim Grisanzio wrote:
>> Ok, here's a third cut at this.
>> http://www.genunix.org/wiki/index.php/OGB_2008/010_OpenSolaris_Constitution_2009
>>
> I updated the wiki formatting (headings and lists) and fixed a typo or
> two there. the
Cool. I got some good editing feedback from Bonnie and I updated the
wiki as well.
> Other comments below:
>
>
>> The OpenSolaris Constitution
>
>> Roles. There are three roles in the OpenSolaris community:
>
>> All of the groups may have have different standards for recognizing
>> people as Participants, Contributors, or Leaders within their
>> respective groups. However, if a participate wants to become a Member
>> of the OpenSolaris community and be engaged in community-wide issues,
>> then he or she has to apply for Membership at the OGB.
>
> I thought we had a lot of discussion and agreement that we wanted
> there to be /some/ common expectations here rather than leaving it
> wide open and unspecified. Something not too hot and not too cold,
> but just right, as Goldilocks said.
Yes, that's why I put in a new section "Group Management Processes" as
a place holder. The OGB can outline some of the basic processes as
suggestions (management, voting, etc), and/or the OGB can mandate that
Groups publish their own specifications.
> This would be one of those non-constitutional procedures things that
> might say something like "Contributers are expected to have
> contributed something substantial to their group; the specifics of
> what that means is expected to vary a lot on a per-group-type basis
> and a little between groups of the same type. A minimal baseline for
> each group type follows...".
Agree.
>> Membership
>>
>> Membership: Participants, Contributors, and Leaders from Communities,
>> Projects, and User Groups may become associated with the Electorate
>> group as voting Members of the OpenSolaris community.
>
> Uhm, as you go on to say:
>
>> ... Only those who have substantially and verifiably contributed to a
>> group may apply for Membership.
>
> By definition, those aren't Participants. The list on the first line
> should only say Contributors and Leaders.
>
Agree. Changed.
>> Group Management Processes
>>
>> Processes: In order to be as consistent as possible and for the
>> purposes mediating disputes, the OGB requests that all groups publish
>> well defined processes for managing their activities.
>
>
> What happens if they don't?
Well, it can be a problem if a real dispute comes up. But many
communities don't follow the Constitution now so I'm not sure what to do
with this. :
> Who reviews them to determine whether or not they are "well defined"
> (or even "not malicious garbage"?)
>
>> If there are no public process documents and if a dispute is brought
>> to the OGB, the board will resolve the issue at its own desertion.
>
> This says groups only need such procedures if there is a dispute.
Well, process documentation should include dispute mechanisms as well.
Perhaps we should specify that.
> To me, this is exactly the worst time to try and invent/interpret such
> procedures. Maybe the group /creation/ process needs to somehow cause
> those procedures/documents to be created...
I think we can add a reference to it in that group creation process as
well. But I'd like to see it flushed out in the Group Management Process
documentation.
>> Meetings of Members
>> ... One-third of the Members,
>> represented in person or by proxy, constitutes a quorum,
>
>> Proxies. Every Member may authorize another person to act on his or
>> her behalf as a Member by Proxy. Every proxy must be signed by the
>> Member and delivered to the Secretary. Proxies are valid for up to
>> one year. All proxies shall be revocable.
>
> An alternative that would keep us out of the eternal "quest for
> quorum" that happens every year would be to adopt some sort of
> "default proxy" mechanism like the following:
>
> We will have a meeting on <date> where votes will be taken
> on the following topics (...). You can attend in person,
> or assign your proxy to another. If you do neither (and
> you can at any time), your proxy will by default be assigned
> to the board to be voted as follows:
> Count for Quorum
> Abstain on all votes (or whatever)
I'm not sure I get this. :) If I don't show up, I'm not counted. But if
my proxy also doesn't show up, how is that counted toward the quorum?
>> Governing Board
>>
>> OGB. The OGB consists of a minimum of three and a maximum of seven
>> natural persons who provide guidance to the OpenSolaris community,
>
> How does the OGB provide guidance? What avenues and mechanisms exist
> for this to happen?
The people on the OGB are Members of the community, and they participate
in Communities, Projects, and User Groups. They are involved in the
community already. They can go out into the community and talk to people
about governance issues. They can deliver presentations at conferences
and user group meetings. They can post announcements to lists about OGB
activities and decisions, etc. They can talk to other communities to get
cross-communication going. They can help people get involved. They can
help build the Membership. They don't need any documented mechanisms for
that, really. It's just a part of leadership.
>> OGB members, upon change of corporate affiliation or other interests
>> related to OpenSolaris, must notify the Membership of their new status.
>
> TODO: Need pointer to a procedure that articulates the details...
Good point. Perhaps we can post to ogb-discuss and opensolaris-announce?
Perhaps we should have a Members list under the new structure?
Personally, I think ogb-discuss is fine.
>> ... starting the first day of the calendar month following the
>> election and continuing until the first day of the
>
> Shouldn't this be:
>
> ... until the *last* day ...
Not sure.
>> calendar month following the next annual meeting. Each OGB member
>> shall hold office for the term for which he or she is elected, until
>> his or her successor us elected, or until his or her earlier
>> resignation, removal, or death. OGB members can serve for up to three
>> consecutive terms.
>
> Add:
> There is no limit on the number of non-consecutive terms a
> member can serve.
I'm fine with that. I'll add a note for discussion.
>> Candidates and Voting. Candidates for election to the OGB must be
>> nominated by a current Member.
>
>
> Is that an "OGB Member" or an "Electorate Member"?
Yah, sorry. It's Member of the community ... or Electorate Member, I
suppose.
> Are we dropping the "and be registered as an OpenSolaris Participant"
> part intentionally?
Well, I assume if you are a Member you are registered.
>> Nominations shall be open seven days
>
> I like the current wording that gives more leway:
>
> Nominations shall be open for a minimum of
> seven (7) days prior to ballot completion.
>
Ok. Changed.
>> prior to ballot completion. An election ballot must be complete and
>> publicly viewable seven days prior to the start of voting. Once voting
>
> Same: Add "at least".
Ok. Changed.
>> has started, the voting shall remain open for seven days. Candidates for
>
> and again: "at least".
>
Ok.
>> Resignations, Removals, and Vacancies. An OGB Member may resign or be
>> removed by an affirmative vote of two-thirds of the Members.
>
> Again, is this an "OGB Member" or an "Electorate Member"?
I believe this means 2/3 of the Members of the community, not the OGB
Members.
>> If the entire OGB resigns
>
>
> This conflicts with the last "Dissolution" section below...
The dissolution section needs work. It's confusing.
>> or if a majority of the community expresses no confidence in an
>> affirmative vote,
>
> Phrasing nit: if the community votes to remove the members of
> the current board through a vote of no confidence,
How about this: "If the entire OGB resigns or if the community votes to
remove the Members of the board through an expression of no confidence,
then a Special Election will be held within thirty days." Just want to
get rid of two "votes" in there ...
>> Meetings. OGB meetings should be held at least once a quarter.
>> Meetings may be held in person or via teleconference, IRC, or
>> equivalent medium for shared communication. OGB meetings are open,
>> but occasionally the OGB may need to discuss confidential items in a
>> closed session. Any decisions resulting from a closed session must be
>> approved in an open meeting.
>
> Should link to http://www.genunix.org/wiki/index.php/OGB_2008/007
>
>
ok.
>> Dispute Resolution
>>
>> Disputes. Disputes should be resolved within groups according to
>> their normal decision-making procedures. If a dispute can not be
>> resolved in a
>
> s/normal/documented/
>
>
>> group or spreads into to the OpenSolaris community generally, then
>> the participants may ask the OGB to help mediate a reasonable
>> solution. The
>
> Can anyone other than the direct participants in a dispute involve
> the OGB? Can the OGB involve itself?
I think someone has to bring a complaint. I can't see the OGB being that
assertive, to be honest.
>> Dissolution
>>
>> If OGB membership is reduced to below three, custody of the
>> OpenSolaris community will revert to Sun Microsystems until such time
>> as the Members elect a new OGB.
Thanks, John. Good comments.
Jim
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
|
|
Posts:
689
From:
GB
Registered:
5/18/05
|
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Nov 21, 2008 6:20 AM
in response to: webmink
|
|
Simon Phipps wrote:
> Travel for the year has ended for me and I am catching up. I can
> answer several of the questions people had about the intent of the
> original - maybe on the OGB call today I can find out which ones are
> still current. I made a cosmetic edit in the Structure section,
> otherwise will wait for discussion before I dive in.
>
> On Nov 13, 2008, at 06:29, Jim Grisanzio wrote:
>
>
>> Updated the wiki a bit:
>> http://www.genunix.org/wiki/index.php/OGB_2008/010_OpenSolaris_Constitution_2009
>>
>>
More updates tonight:
* clarified Sun's role when the OGB falls under 3 members
* removed references to proxies
* removed references to meeting of members and replaced with election
* a bunch of text changes
* simon updated the elections section
Check the history for anything I missed ...
Jim
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
824
From:
US
Registered:
3/9/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Dec 16, 2008 2:25 PM
in response to: jimgris
To: Communities » ogb » discuss
|
|
> * removed references to meeting of members and
> replaced with election
In the section on suspended members, should the references to "meetings" be changed to "elections"?
Also, the section on Expulsion says "The OGB may expel a participant by an affirmative vote of a two-thirds majority of the Members."
This wording is confusing about whose votes count. Normally "Members" (as opposed to "OGB Members") is used to mean "Members of the community". But in that case it would be more appropriate to say that the community may expel a participant.
And if "Members of the community" is meant, please clarify whether this is an absolute requirement, or if it means 2/3 of the Members who are voting (assuming quorum is reached).
thanks,
mike
|
|
|
|
|
Stephen Lau
stevel@opensolaris.org
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 15, 2008 11:18 AM
in response to: jimgris
|
|
On 10/15/08 1:56 AM, Jim Grisanzio wrote:
> Article 1. Name: Removed. I'm not sure how to handle this because this
> section refers to the Charter, and we have to consider the Charter in
> this as well. I never really saw a connection between the Charter and
> Constitution, so my view is that we don't even need a Charter and the
> Constitution should stand on its own. But we can deal with that in
> subsequent drafts.
It was always my understanding that the only document that actually had
any real authority was the Charter as that was essentially the document
that gave the community power to use Sun trademarks and govern itself.
I'm not so sure we can disregard it?
cheers,
steve
--
stephen lau | stevel at opensolaris dot org | www.whacked.net
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 15, 2008 2:30 AM
in response to: carlsonj
|
|
On 10/09/08 03:34, James Carlson wrote:
<pre wrap="">Tim Cramer writes:
</pre>
<pre wrap="">High-level: why appointment via Sun rather than a new election? Again, I'm
not saying this is right or wrong, just curious as to the rationale.
</pre>
<pre wrap="">Didn't realize this was in the constitution. Currently, unless I'm
mistaken, if someone "leaves" the board for whatever reason, the next
person from the previous election results would take over in vote
totals, is that correct? Would we continue that process until we ran
out of candidates and then hit this? If so, a "re election" seems more
appropriate, I'd be really surprised if we hit that case.
</pre>
<pre wrap=""><!---->
That'd be sections 6.4 and 6.5.
6.4 says that if the OGB members all quit or die at once, then there's
a special election. (Article X gives the authority to call that
election and declare the results to Sun, but doesn't really describe
how "Sun" should take that up.)
6.5 says that if an OGB member is *removed* (rather than just quits),
then the vacancy is cannot be filled until the next election. I guess
if the Members held a vote of "no confidence" in each member one at a
time, you'd eventually end up with a too-small OGB, and trip over
Article X.
The previous election results matter only if someone quits or dies in
office, and then only if the required minimum are left in order to
have an official OGB meeting to handle the problem
</pre>
I tried to combine some of these sections so they are not spread out.
Also, if Sun had to appoint a new board, the obvious choice to do it
would be the exec representative (currently T. Cramer). But then things
can continue as per the constitution and the next election comes around
as scheduled.
Jim
<pre class="moz-signature" cols="72">--
http://blogs.sun.com/jimgris/
</pre>
|
|
|
|
|
Posts:
3,835
From:
JP
Registered:
4/6/05
|
|
|
|
Re: [ogb-discuss] The OpenSolaris Constitution: (Really Rough) v2.0
Posted:
Oct 15, 2008 2:02 AM
in response to: jbeck
|
|
On 10/09/08 02:02, John Beck wrote:
> Jim> ... You can reactivate your Membership up to 14 days after a
> Jim> community wide election is announced.
>
> Jim> ... The OGB shall provide notice to the community not less than
> Jim> ten days or more than sixty days before the date of the meeting...
>
> High-level: I think having 14 days for the one and 10 days for the other
> is bad; those two values should match. Later text (7 days for nominations
> and 7 days for public view) suggests that 14 is the better choice.
>
These days confuse me, to be honest. :) We'll have to talk about it on
the next call.
> Jim> ... OGB members can serve for three consecutive terms.
>
> Wording nit: s/for three/for up to three/
>
>
> Jim> In the event that there are no further candidates from the prior
> Jim> election, or if the vacancy is due to the removal of an OGB member,
> Jim> the vacancy shall not be filled until the next OGB election.
>
> High-level: why would the vacancy not be filled if due to removal? There
> may be a case for this position, but it is not obvious to me.
>
Not sure. That's what's in the current Constitution. I actually changed
it in my draft so we can discuss it.
> Jim> This Constitution may be updated or repealed by an affirmative vote of
> Jim> a majority of the Members during annual meetings
>
> High-level: only during annual meetings? I would think a special election
> would also suffice.
>
Agree. Changed to both.
> Jim> If the OGB is reduced in membership below the minimum of three members,
> Jim> Sun Microsystems shall appoint a new board.
>
> High-level: why appointment via Sun rather than a new election? Again, I'm
> not saying this is right or wrong, just curious as to the rationale.
>
Changed to state that Sun appoints a new board if the OGB falls below 3
members and then normal operations continue. That's basically what the
current Constitution says. My initial edit was incorrect. I didn't
intend to change meaning here.
Jim
--
http://blogs.sun.com/jimgris/
_______________________________________________
ogb-discuss mailing list
ogb-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/ogb-discuss
|
|
|
|
|
