[OpenDaylight TSC] [OPENDAYLIGHT BYLAW WAIVER - TSC COMPOSITION] Discussion.

Phil Robb probb at linuxfoundation.org
Wed Oct 21 23:33:44 UTC 2015


Hello:


This email is to kick off a discussion on how to plan for the removal of
the Waiver to the OpenDaylight ByLaws each time we want to run a TSC
Committer-At-Large election.


For context, The Board met on 7 October 2015 where the following motion was
made:

====

CONSIDER: That the requirement stated in Section 5.5(b) of the

OpenDaylight Second Amended and Restated By-laws of the Company, as so
amended, which reads:

"If an event occurs causing a non-designated TSC member associated with a

given Platinum Member to join the TSC, the designated TSC member must step
down immediately"

is hereby waived for the period of one year from 07 October 2015 through 06

October 2016 in the event that such event occurs.

====

This motion failed to receive the votes required to pass.  The discussion
that ensued around this motion had the following points:


   1.

   The waiver is needed because we have in our Bylaws that Platinum Members
   of the OpenDaylight Project nonprofit organization have the right to
   designate an employee from their company to sit on the TSC.  The ByLaws
   also state that "This right will be re-evaluated by the Board annually and
   may be eliminated by Super-Majority Vote of the Boared when the Baord
   believes it is no longer necessary..."
   2.

   With Platinum designates in place, members of the TSC (who were present
   at the Board meeting) felt that a valid Committer-At-Large election could
   only be executed if the waiver were in place.  Otherwise, too many valid
   candidates choose not to run and risk “bumping” their company’s designate
   from his/her place on the TSC.
   3.

   Given that OpenDaylight is 2.5 years old, there was a common belief
   among Board members that there are capable, seasoned technical leaders
   within the OpenDaylight developer community from which a valid and robust
   TSC could be formed without the need for Platinum Member designates.
   4.

   The Board felt that the waiver is an explicit circumvention of the
   Bylaws.  As such they were not comfortable with approving the waiver for a
   second time without first understanding a plan for when such a waiver would
   no longer be needed.  Without an expected end-date for the need of the
   waiver, they did not want to approve it for the coming year.
   5.

   This working group was then tasked with exploring ways in which the
   project and TSC can move forward in the future without the need for such a
   waiver.


I think the first question we need to ask is “Is there any way to remove
the need for the waiver while still allowing Platinum members to designate
TSC representatives?”.  Again, the consensus during the Board meeting was
“no”, but it is a logical place for us to begin our discussions.  Please
provide your thoughts.

If we were to remove the Platinum Member designates from the TSC, one
question to ask is:  Would we want to alter the current method for
populating the TSC?  As a reminder, the current TSC is populated from three
separate “pools”:

   1.

   Platinum Member Designates (currently 8)
   2.

   Elected Committers-At-Large (currently 2… soon to go to 4)
   3.

   Core Project Technical Leaders (currently 0)


So if we were to remove the Platinum Member designates today, we would only
have the Committers-At-Large on the TSC.  What are some of the other ways
we might want to populate the TSC?

One method may be to add other/additional “pools” from which to draw TSC
members.  Examples of these include:


   -

   PTLs from Mature projects
   -

   PTLs from Incubation projects
   -

   ODL Release Manager(s)
   -

   ODL Release Engineer(s)
   -

   If we were to have working groups such as an “Architecture Advisory
   Group”, having a representative from such a group
   -

   Other?


To scope how we might want to draw such pools, should we set a target size
(range) for the TSC?

With a target size/range identified, what proportion of the target
size/range would we allocate from each candidate pool?

Finally, should we consider suggested or mandatory corporate diversity? I.e
“No commercial entity shall employ more that X% (10?, 20?, 30?) of TSC
members”... or “No commercial entity shall employ more than X (2?, 3?, 4?)
 number of TSC members”.

There are a variety of ways to address the above challenge.  The examples I
provide here are only to get the thought-process started.  Please
respond-all to share your thoughts on the above options or by all means
suggest new alternatives.

If you have any questions or comments please don’t hesitate to contact me.

Best regards,

Phil.
-- 
Phil Robb
Sr. Director Of Technical Operations
OpenDaylight Project
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/tsc/attachments/20151021/e9dca074/attachment-0001.html>


More information about the TSC mailing list