On Apr 26, 2014, at 7:53 AM, Giovanni Meo <gmeo@...> wrote:

Hi all,

i know the question Phil has raised are addressed to the TSC members, but i feel
like i should also say my point of view, being part of the community.

Regarding the point 1) the Option 1:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove the "If Otherwise Not Represented" clause from the By-Laws and Charter
document as it relates to Platinum Member designates to the TSC #3 above
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Seems more appropriate to me also because personally i have been doing the
nominations assuming this behavior (of course I should have read the legal paper
before and i didn't, shame on me). I think "Option 1" is correct because i want
to make sure that when i nominate someone i'm free to pick a person that has
technical merits without worrying that person would think i want to shutdown
that company TSC member. The current behavior basically penalize the folks that
works for platinum members from being freely elected. Also i would like to point
out that even though many of us works for corporates, the corporate membership
is subject to change while the technical merits of person are a more stable
parameter and i believe we want to recognize that.

Regarding the point 2) i would like to propose a category "c":

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Those that:
- contributed code
or
- documentation
or
- opened bugs

during the solar year before the election (till the date when the nomination
request goes out).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I would like to propose this because:

A) Who opens bugs is very important to do a reality check on the code, because
if the code is coin of realm, i would argue that the bugs are the reality check
of it, and as such someone that is contributing testing is very valuable.
Clearly someone that do test and find a bug often may fix it also, but given we
are in the field of SDN some of the field operator testing ODL may not feel
confident to contribute a bug fix yet their input is very much appreciated as
field expert.

B) Adding the constraints on the time allows to consider folks that has been
active in the near past not in the distant past.

Regarding the point 3) if we empathize more on peoples value than on the
affiliation with corporate probably this become less relevant. In the end people
affiliation either via contracting or being employed by a company are subject to
change while person value generally stays.

My 2 cents,
Giovanni

On 22-Apr-14 22:31, Phil Robb wrote:
Hello members of the TSC:

This email is to kick off a discussion of what, if any, changes are to be
proposed to the OpenDaylight Board regarding the At-Large TSC election. As you
may recall, the TSC requested a delay of the vote for two TSC At-Large members
due to a variety of consequences that were either not or poorly understood by
the committer population and those nominated. At their April meeting, the
Board has requested that the TSC delay the election for 60 days while a proposal
is brought forward to facilitate an agreed election by the Board and the TSC.
As a point of reference, 60 days from the April 2nd Board meeting is June 1st.

Currently, the ByLaws [1] and TSC charter [2] identify 3 ways in which an
individual can become a member of the TSC.

1) Project Technical Leaders (PTLs) for projects within OpenDaylight that are
"Core" projects as defined by the Project Lifecycle [3] shall each have a seat
on the TSC. Note that it does not matter what organization any of the PTLs come
from. If the person is a PTL on a "Core" project, then they have a seat on the
TSC regardless of company affiliation. There is only one PTL per project.

2) At-Large Committers - Any person holding committer rights on any OpenDaylight
project is eligible to run for these TSC seats. Currently, the TSC has
identified that there will be 2 At-Large Committer seats available on the TSC.
Note that all At-Large TSC members must come from separate companies. These
At-Large TSC members may also come from a company that has a PTL-based TSC seat,
but not another At-Large TSC seat.

3) If not otherwise represented (through #1 and #2 above), each Platinum member
of the OpenDaylight Project may designate 1 TSC member.

As we attempted to hold Committer nominations and then an election for the two
At-Large Committer TSC seats, the majority of those nominated chose to decline
their nomination. The common reason stated for declining was that those
nominated did not want to displace the existing TSC members that had been
designated by their employer because those existing TSC members were doing a
very good job leading the technical community and to lose them would have a
noticeable, negative impact on the project.

The vast majority of the existing TSC members are not committers on the project
but have made huge contributions through their leadership on the TSC. So they
are not eligible to run for At-Large TSC seats. Therefore, if a committer from
the same organization is elected to the At-Large position, the existing Platinum
Designate must step down even if he/she is very highly valued in that role by
the technical community.

*1) So the first discussion/decision is to determine if there is a way to
increase and improve the diversity of the technical community representation on
the TSC, as is intended by the At-Large Committer positions, while preserving
the strong leadership base already present within the existing TSC.

To get the discussion going, I present below a variety of the options that I
have heard from the community. Please provide comments and refinements to
these, or totally different options if you are so inclined. The goal is for the
TSC members to gravitate to one or two options on which a vote can be made in an
upcoming TSC meeting. Once that is done, we will provide our recommendation to
the Board for consideration and feedback.

Option 1 - Remove the "If Otherwise Not Represented" clause from the By-Laws
and Charter document as it relates to Platinum Member designates to the TSC (#3
above).
Pros -
Simple solution to immediate problem. The addition of a single At-Large
Committer TSC member will not force any existing Platinum Member designate TSC
member to step down.
Cons -
Allows for some corporate members of the community to have more
representation on the TSC than had been allowed previously

Option 2 - Allow existing TSC members to run for re-election
Pros -
Allows the existing TSC members (even if they are not committers) to stand
for election head to head with the other nominated candidates. The Committers
of OpenDaylight can make an apples-to-apples comparison of who they would prefer
to have as technical leaders.
Cons -
Still may not allow for the perceived best candidates to win if two (or
more) highly qualified candidates come from the same company
Allows for non-committers to be elected to At-Large committer TSC seats.

Option 3 - Do nothing; Leave everything the same and let the voting fall where
it may.
Pros - No changes to original ByLaws/Charter
Cons - Potentially puts large "holes" in TSC knowledge base through displacement
of valued TSC members, or by having the majority of strong committer candidates
decline their nominations.

Option 4 - Please add more options if you have them.

Additional ByLaw/Charter changes that have been discussed as part of this
activities - The TSC may want to also address these in this discussion, or
defer them until after *1 has been fully resolved.

*2) Widen the At-Large population who can run and vote. Currently, only
committers can run, or vote for the At-Large TSC member seats. Proposals that
have been suggested include:
a. Those that contribute code to the OpenDaylight project (Code Contributors)
should be included.
b. Those that contribute either code or documentation to the OpenDaylight
project (Code/Doc contributors) should be included.

Pros -
Expands the pool of candidates for nomination and voting.
Cons -
Increases the potential for less-active members of the community to gain
greater influence

*3) Explicitly call out contractor affiliation with an OpenDaylight member
company. Currently contractors that are working for member companies within the
OpenDaylight community are recognized as working for their contracting company
(or as individuals) and not for the member company to which they contract. This
does not properly represent the true affiliation between the contractor and the
member company.
Pros - Better identifies member company affiliations
Cons - Setting the criteria for "what is a contractor" is non-trivial. Within
the OpenStack community for example an affiliated contractor is one that earns
more than $60,000USD annually from the member company. In addition, the Board
of OpenStack has the final say in determining affiliation. We would need to set
this criteria to meet ODL's needs.

For each TSC member, please comment on *1 with your questions, concerns, support
or lack there of for the options presented, or alternately, propose an altered
version, or a new one all together. For items *2 and *3, please indicate if you
would like to defer each discussion, and if not, what are your thoughts on each.

Thank you very much for your consideration of these topics.

Phil

[1] TSC Charter - http://www.opendaylight.org/project/tsc/charter (section 4)
[2] OpenDaylight ByLaws - http://www.opendaylight.org/project/bylaws (section
5.5(b))
[3] http://www.opendaylight.org/project-lifecycle-releases

--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb


_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss

--
Giovanni Meo
Via del Serafico, 200 Telephone: +390651644000
00142, Roma Mobile: +393480700958
Italia Fax: +390651645917
VOIP: 8-3964000
“The pessimist complains about the wind;
the optimist expects it to change;
the realist adjusts the sails.” -- Wm. Arthur Ward
IETF credo: "Rough consensus and running code"
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss