Date   

Increasing TSC meetings to twice per week

Phil Robb
 

Hello OpenDaylight TSC Members:

As Dave mentioned in a previous mail, the TSC is not making as much progress as is needed during the weekly calls that are occurring.  While the discussions and exchange of ideas are excellent,  we are routinely not getting through the agenda which is resulting in items being repeatedly deferred from one week to the next.

We suggest that the TSC add another hour onto our weekly schedules to overcome this increased start-up workload.  We can drop back down to weekly meetings once we are through this initial push.

I would like to suggest that we add a meeting from 10:00am to 11:00am on Tuesday mornings in addition to the one hour (10:00am - 11:00am Thursdays) meetings already scheduled.

Alternatively we could expand the meeting on Thursdays to 2 hours.

Please let me know if you could accomodate a 10am PDT meeting on Tuesdays.  Your help in this is greatly appreciated.  As everyone knows. we have much to get done before our first release in September.

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


Re: Asynchronous voting mechanisms for TSC

Thomas Nadeau <tnadeau@...>
 

I guess any motions that are raised during the call, in cases where %100
of members are not there, must then also be sent out via email (with an
expiration date to absentee votes). Although we should count attendees at
the time its called.

--Tom

* David Meyer (dmm@...) wrote:
<snip>
Finally, we aren't
really making as much progress as I would like (you'll see an update
from
Phil on this) and as such using "quorum authority" helps us execute.
Here are a couple concrete steps we could follow to encourage more
email use:

1) require that all agenda items are added to the wiki w/in Xhrs/days
of the next call, and include a cc to the list (alternatively, we place
a watch on the agenda wiki such that updates are sent to the list)

2) use email to put forth motions allowing for time before meeting to
actually vote.

The goal of both of those is to push the bulk of the conversation
surrounding the topic to the list before a tsc meeting to streamline
the realtime part of the conversation.

thanks,
-chris
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc


Re: Asynchronous voting mechanisms for TSC

David Meyer <dmm@...>
 

Great suggestions. --dmm


On Thu, Apr 25, 2013 at 2:58 PM, Chris Wright <chrisw@...> wrote:
* David Meyer (dmm@...) wrote:
<snip>
> Finally, we aren't
> really making as much progress as I would like (you'll see an update from
> Phil on this) and as such using "quorum authority" helps us execute.

Here are a couple concrete steps we could follow to encourage more
email use:

1) require that all agenda items are added to the wiki w/in Xhrs/days
of the next call, and include a cc to the list (alternatively, we place
a watch on the agenda wiki such that updates are sent to the list)

2) use email to put forth motions allowing for time before meeting to
actually vote.

The goal of both of those is to push the bulk of the conversation
surrounding the topic to the list before a tsc meeting to streamline
the realtime part of the conversation.

thanks,
-chris


Re: Asynchronous voting mechanisms for TSC

Chris Wright <chrisw@...>
 

* David Meyer (dmm@...) wrote:
<snip>
Finally, we aren't
really making as much progress as I would like (you'll see an update from
Phil on this) and as such using "quorum authority" helps us execute.
Here are a couple concrete steps we could follow to encourage more
email use:

1) require that all agenda items are added to the wiki w/in Xhrs/days
of the next call, and include a cc to the list (alternatively, we place
a watch on the agenda wiki such that updates are sent to the list)

2) use email to put forth motions allowing for time before meeting to
actually vote.

The goal of both of those is to push the bulk of the conversation
surrounding the topic to the list before a tsc meeting to streamline
the realtime part of the conversation.

thanks,
-chris


Re: TSC Comments to the Board on TSC_Policy.doc

Chris Wright <chrisw@...>
 

* Rob Sherwood (rob.sherwood@...) wrote:
The list definitely looks accurate - thanks Ed.

One thing: I'm sure that Dave, Benson, Chris and others will provide the
necessary context around these changes, but I can imagine if you see these
proposed changes without that context, one could jump to some incorrect
conclusions. Do the TSC members who are also on the board feel comfortable
representing _why_ the changes were made?
Yes


Re: TSC Comments to the Board on TSC_Policy.doc

David Meyer <dmm@...>
 



On Thu, Apr 25, 2013 at 1:21 PM, Rob Sherwood <rob.sherwood@...> wrote:
The list definitely looks accurate - thanks Ed.

One thing: I'm sure that Dave, Benson, Chris and others will provide the necessary context around these changes, but I can imagine if you see these proposed changes without that context, one could jump to some incorrect conclusions.  Do the TSC members who are also on the board feel comfortable representing _why_ the changes were made?

Not a problem. --dmm
 

Thanks,

- Rob


On Thu, Apr 25, 2013 at 12:10 PM, David Meyer <dmm@...> wrote:


On Thu, Apr 25, 2013 at 12:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
Please find enumerated below the comments of the TSC on the Boards TSC-policies doc.  In addition, please find attached
a redline of that doc.

This is an output of the 2013-04-25 TSC meeting. Please respond with any comments as to the fidelity with which these
decisions are captured in this email (I think I got it right… but many eyeballs make all bugs shallow :) ).

1. Comment to the Board: The TSC recommends replacing the word 'mature' in the 'Singularity' bullet with the word 'core'.

2. Comment to the Board: The TSC recommends striking the 'Effectiveness' bullet all together on the grounds that resources and priority are
driven bottom up, not top down from the TSC.

3. Comment to the Board: The TSC recommends striking the 'Productivity' bullet and replacing it with a bullet
"•      Simultaneous Release:  The TSC is responsible for organizing a simultaneous release of appropriate OpenDaylight Projects at regular intervals."

4. Comment to the Board: The TSC needs a lightweight mechanism to request an  adjustment of scope for the OpenDaylight project to the  Board of Directors as needed.

5. Comment to the Board: With regard to the “Reference forwarding elements” in the OpenDaylight scope, the TSC recommends an
alternate description of “Software for forwarding  elements”.

6. Comment to the Board: The TSC recommends adding an additional item to the
scope, that being “Plugins for inter-controller  communication”

Thanks Ed. This looks to accurately capture what we decided. Others: If you have corrections/discussion points/etc please get those to the list by COB and I will synthesize a package for the Board (hopefully by tomorrow if we can close on this list).

Thnx,

--dmm



_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc




Re: TSC Comments to the Board on TSC_Policy.doc

Phil Robb
 

For clarity, you might also want to add that comments 4 through 6 are in reference to the "Scope" portion of the document.

Phil.


On Thu, Apr 25, 2013 at 2:21 PM, Rob Sherwood <rob.sherwood@...> wrote:

The list definitely looks accurate - thanks Ed.

One thing: I'm sure that Dave, Benson, Chris and others will provide the necessary context around these changes, but I can imagine if you see these proposed changes without that context, one could jump to some incorrect conclusions.  Do the TSC members who are also on the board feel comfortable representing _why_ the changes were made?

Thanks,

- Rob


On Thu, Apr 25, 2013 at 12:10 PM, David Meyer <dmm@...> wrote:


On Thu, Apr 25, 2013 at 12:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
Please find enumerated below the comments of the TSC on the Boards TSC-policies doc.  In addition, please find attached
a redline of that doc.

This is an output of the 2013-04-25 TSC meeting. Please respond with any comments as to the fidelity with which these
decisions are captured in this email (I think I got it right… but many eyeballs make all bugs shallow :) ).

1. Comment to the Board: The TSC recommends replacing the word 'mature' in the 'Singularity' bullet with the word 'core'.

2. Comment to the Board: The TSC recommends striking the 'Effectiveness' bullet all together on the grounds that resources and priority are
driven bottom up, not top down from the TSC.

3. Comment to the Board: The TSC recommends striking the 'Productivity' bullet and replacing it with a bullet
"•      Simultaneous Release:  The TSC is responsible for organizing a simultaneous release of appropriate OpenDaylight Projects at regular intervals."

4. Comment to the Board: The TSC needs a lightweight mechanism to request an  adjustment of scope for the OpenDaylight project to the  Board of Directors as needed.

5. Comment to the Board: With regard to the “Reference forwarding elements” in the OpenDaylight scope, the TSC recommends an
alternate description of “Software for forwarding  elements”.

6. Comment to the Board: The TSC recommends adding an additional item to the
scope, that being “Plugins for inter-controller  communication”

Thanks Ed. This looks to accurately capture what we decided. Others: If you have corrections/discussion points/etc please get those to the list by COB and I will synthesize a package for the Board (hopefully by tomorrow if we can close on this list).

Thnx,

--dmm



_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc




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


Re: TSC Comments to the Board on TSC_Policy.doc

Rob Sherwood
 

The list definitely looks accurate - thanks Ed.

One thing: I'm sure that Dave, Benson, Chris and others will provide the necessary context around these changes, but I can imagine if you see these proposed changes without that context, one could jump to some incorrect conclusions.  Do the TSC members who are also on the board feel comfortable representing _why_ the changes were made?

Thanks,

- Rob


On Thu, Apr 25, 2013 at 12:10 PM, David Meyer <dmm@...> wrote:


On Thu, Apr 25, 2013 at 12:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
Please find enumerated below the comments of the TSC on the Boards TSC-policies doc.  In addition, please find attached
a redline of that doc.

This is an output of the 2013-04-25 TSC meeting. Please respond with any comments as to the fidelity with which these
decisions are captured in this email (I think I got it right… but many eyeballs make all bugs shallow :) ).

1. Comment to the Board: The TSC recommends replacing the word 'mature' in the 'Singularity' bullet with the word 'core'.

2. Comment to the Board: The TSC recommends striking the 'Effectiveness' bullet all together on the grounds that resources and priority are
driven bottom up, not top down from the TSC.

3. Comment to the Board: The TSC recommends striking the 'Productivity' bullet and replacing it with a bullet
"•      Simultaneous Release:  The TSC is responsible for organizing a simultaneous release of appropriate OpenDaylight Projects at regular intervals."

4. Comment to the Board: The TSC needs a lightweight mechanism to request an  adjustment of scope for the OpenDaylight project to the  Board of Directors as needed.

5. Comment to the Board: With regard to the “Reference forwarding elements” in the OpenDaylight scope, the TSC recommends an
alternate description of “Software for forwarding  elements”.

6. Comment to the Board: The TSC recommends adding an additional item to the
scope, that being “Plugins for inter-controller  communication”

Thanks Ed. This looks to accurately capture what we decided. Others: If you have corrections/discussion points/etc please get those to the list by COB and I will synthesize a package for the Board (hopefully by tomorrow if we can close on this list).

Thnx,

--dmm



_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



Re: TSC Comments to the Board on TSC_Policy.doc

David Meyer <dmm@...>
 



On Thu, Apr 25, 2013 at 12:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
Please find enumerated below the comments of the TSC on the Boards TSC-policies doc.  In addition, please find attached
a redline of that doc.

This is an output of the 2013-04-25 TSC meeting. Please respond with any comments as to the fidelity with which these
decisions are captured in this email (I think I got it right… but many eyeballs make all bugs shallow :) ).

1. Comment to the Board: The TSC recommends replacing the word 'mature' in the 'Singularity' bullet with the word 'core'.

2. Comment to the Board: The TSC recommends striking the 'Effectiveness' bullet all together on the grounds that resources and priority are
driven bottom up, not top down from the TSC.

3. Comment to the Board: The TSC recommends striking the 'Productivity' bullet and replacing it with a bullet
"•      Simultaneous Release:  The TSC is responsible for organizing a simultaneous release of appropriate OpenDaylight Projects at regular intervals."

4. Comment to the Board: The TSC needs a lightweight mechanism to request an  adjustment of scope for the OpenDaylight project to the  Board of Directors as needed.

5. Comment to the Board: With regard to the “Reference forwarding elements” in the OpenDaylight scope, the TSC recommends an
alternate description of “Software for forwarding  elements”.

6. Comment to the Board: The TSC recommends adding an additional item to the
scope, that being “Plugins for inter-controller  communication”

Thanks Ed. This looks to accurately capture what we decided. Others: If you have corrections/discussion points/etc please get those to the list by COB and I will synthesize a package for the Board (hopefully by tomorrow if we can close on this list).

Thnx,

--dmm



_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



Re: Asynchronous voting mechanisms for TSC

David Meyer <dmm@...>
 



On Thu, Apr 25, 2013 at 11:18 AM, Benson Schliesser <bensons@...> wrote:
Hi, Rob.

Just my opinion as an observer of the TSC: 

First, if the TSC ever needs such a mechanism, I'd suggest a web poll. It's much easier than asking somebody to coordinate between phone calls, emails, etc. (For example, I've used Doodle for such polls in the past - many other tools exist, and/or a private tool could be hosted on the OpenDaylight servers.)

That being said, I note that much of the TSC polling seems to be a result of conversational back-and-forth. It would be unfortunate to lose that kind of fast-acting collaboration. I think this is at the root of DMM's comment about having the authority of "quorum" at TSC meetings. So while it might make sense to have an async poll option in the TSC process toolbox, I'd discourage the TSC from relying on it too much.

All, thanks for the thoughts.

A few comments: First, I don't want to see any TSC member disenfranchised due to travel, overbooking, etc. We're all busy. In addition,,  according to Robert's Rules of Order Newly Revised (http://en.wikipedia.org/wiki/Robert%27s_Rules_of_Order), the "requirement for a quorum is protection against totally unrepresentative action in the name of the body by an unduly small number of persons."  Finally, we aren't really making as much progress as I would like (you'll see an update from Phil on this) and as such using "quorum authority" helps us execute.

All of that said, let's continue to discuss/explore how we can be more flexible and accommodating of people's time/commitments. 

--dmm



Cheers,
-Benson



On 4/25/13 2:07 PM, Rob Sherwood wrote:
I don't want to distract the call with this, but I think it's an important topic that we can hopefully take up on the mailing list: we probably should create a mechanism for allowing TSC members to vote asynchronously (e.g., via email) if they cannot make the call for what ever reason.  A bunch of us have heavy travel schedules and I'm trying to push for a reasonable policy before this becomes an issue rather than after.

I heard what Dave said about having quorum, but IMHO it would be great if we allowed, independent of quorum, people to "mail in" a vote under some sort of finite time window.    

Specifically, I thinking something like:

* If a vote is scheduled in advance, people can submit a vote anytime before the meeting on that issue.

* For any vote (scheduled or unscheduled), a TSC member who was absent from the meeting way submit a vote up until 24 hours after the TSC meeting.

* Legal methods for submitting a vote include phone call or email to a Linux Foundation representative (probably Phill Robb).  The Linux Foundation will then (as always) publicly post the result of the vote so if there is any discrepancy, it can be resolved as appropriate.

What do people think about something like this?  I'm not particularly hung up on any of the specifics here (e.g., if 24 hours is too long or short, if you don't want to allow "vote by phone", etc.) but I'd like to see something in this spirit setup.

Thoughts?

TIA,

- Rob
.



_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc


_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc



Re: Asynchronous voting mechanisms for TSC

Benson Schliesser <bensons@...>
 

Hi, Rob.

Just my opinion as an observer of the TSC: 

First, if the TSC ever needs such a mechanism, I'd suggest a web poll. It's much easier than asking somebody to coordinate between phone calls, emails, etc. (For example, I've used Doodle for such polls in the past - many other tools exist, and/or a private tool could be hosted on the OpenDaylight servers.)

That being said, I note that much of the TSC polling seems to be a result of conversational back-and-forth. It would be unfortunate to lose that kind of fast-acting collaboration. I think this is at the root of DMM's comment about having the authority of "quorum" at TSC meetings. So while it might make sense to have an async poll option in the TSC process toolbox, I'd discourage the TSC from relying on it too much.

Cheers,
-Benson


On 4/25/13 2:07 PM, Rob Sherwood wrote:

I don't want to distract the call with this, but I think it's an important topic that we can hopefully take up on the mailing list: we probably should create a mechanism for allowing TSC members to vote asynchronously (e.g., via email) if they cannot make the call for what ever reason.  A bunch of us have heavy travel schedules and I'm trying to push for a reasonable policy before this becomes an issue rather than after.

I heard what Dave said about having quorum, but IMHO it would be great if we allowed, independent of quorum, people to "mail in" a vote under some sort of finite time window.    

Specifically, I thinking something like:

* If a vote is scheduled in advance, people can submit a vote anytime before the meeting on that issue.

* For any vote (scheduled or unscheduled), a TSC member who was absent from the meeting way submit a vote up until 24 hours after the TSC meeting.

* Legal methods for submitting a vote include phone call or email to a Linux Foundation representative (probably Phill Robb).  The Linux Foundation will then (as always) publicly post the result of the vote so if there is any discrepancy, it can be resolved as appropriate.

What do people think about something like this?  I'm not particularly hung up on any of the specifics here (e.g., if 24 hours is too long or short, if you don't want to allow "vote by phone", etc.) but I'd like to see something in this spirit setup.

Thoughts?

TIA,

- Rob
.



_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc


TSC Comments to the Board on TSC_Policy.doc

Ed Warnicke (eaw) <eaw@...>
 

Please find enumerated below the comments of the TSC on the Boards TSC-policies doc. In addition, please find attached
a redline of that doc.

This is an output of the 2013-04-25 TSC meeting. Please respond with any comments as to the fidelity with which these
decisions are captured in this email (I think I got it right… but many eyeballs make all bugs shallow :) ).

1. Comment to the Board: The TSC recommends replacing the word 'mature' in the 'Singularity' bullet with the word 'core'.

2. Comment to the Board: The TSC recommends striking the 'Effectiveness' bullet all together on the grounds that resources and priority are
driven bottom up, not top down from the TSC.

3. Comment to the Board: The TSC recommends striking the 'Productivity' bullet and replacing it with a bullet
"• Simultaneous Release: The TSC is responsible for organizing a simultaneous release of appropriate OpenDaylight Projects at regular intervals."

4. Comment to the Board: The TSC needs a lightweight mechanism to request an adjustment of scope for the OpenDaylight project to the Board of Directors as needed.

5. Comment to the Board: With regard to the “Reference forwarding elements” in the OpenDaylight scope, the TSC recommends an
alternate description of “Software for forwarding elements”.

6. Comment to the Board: The TSC recommends adding an additional item to the
scope, that being “Plugins for inter-controller communication”


Asynchronous voting mechanisms for TSC

Rob Sherwood
 

I don't want to distract the call with this, but I think it's an important topic that we can hopefully take up on the mailing list: we probably should create a mechanism for allowing TSC members to vote asynchronously (e.g., via email) if they cannot make the call for what ever reason.  A bunch of us have heavy travel schedules and I'm trying to push for a reasonable policy before this becomes an issue rather than after.

I heard what Dave said about having quorum, but IMHO it would be great if we allowed, independent of quorum, people to "mail in" a vote under some sort of finite time window.    

Specifically, I thinking something like:

* If a vote is scheduled in advance, people can submit a vote anytime before the meeting on that issue.

* For any vote (scheduled or unscheduled), a TSC member who was absent from the meeting way submit a vote up until 24 hours after the TSC meeting.

* Legal methods for submitting a vote include phone call or email to a Linux Foundation representative (probably Phill Robb).  The Linux Foundation will then (as always) publicly post the result of the vote so if there is any discrepancy, it can be resolved as appropriate.

What do people think about something like this?  I'm not particularly hung up on any of the specifics here (e.g., if 24 hours is too long or short, if you don't want to allow "vote by phone", etc.) but I'd like to see something in this spirit setup.

Thoughts?

TIA,

- Rob
.


Webex for today's call (now)

Phil Robb
 

Is here:

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


Re: Possible board/tsc communication breakdown

Ed Warnicke (eaw) <eaw@...>
 

Actually... this suggests a possible suggestion to the board that they email such taskings to the TSC to the TSC list ccing whatever list the board has so everyone is on page :)

Ed

On Apr 25, 2013, at 9:42 AM, "David Meyer" <dmm@...> wrote:



On Thu, Apr 25, 2013 at 7:39 AM, Ed Warnicke (eaw) <eaw@...> wrote:
I was simply seeking clarification as you sit on both the TSC and board meetings and could thus speak directly :)

Everything is new and moving fast :)


Sure :-) 

Just wanting everything (including communications such as these) to be in the open. In addition, I want to establish that *anyone* can open such a thread on tsc@lists.

--dmm
 
Ed

On Apr 25, 2013, at 9:33 AM, "David Meyer" <dmm@...> wrote:



On Thu, Apr 25, 2013 at 7:19 AM, David Meyer <dmm@...> wrote:


On Thu, Apr 25, 2013 at 6:57 AM, Ed Warnicke (eaw) <eaw@...> wrote:
Dave,
        I've had two things bubbling back to me about board/tsc communication that concern me:

1)  It's been reported to me that our original feedback to the board on the scope did not actually make it
to the board.

I told Inder that we had more extensive edits (as evidenced by, for example, Rob's comments this morning) to the document and I wanted to wait until we had all of the input  incorporated into one package before we gave it to the board. The theory here is that I didn't want to send several drafts with different edits to the board. If you think this should have been handled differently, please raise it on the call.

2)  It's been reported to me that the draft before us was not actually sent to us by the board, but rather unilaterally
        by the chair, not incorporating board feedback.

BTW, in re-reading 2) I'll just note that I consider Inder to speak authoritatively for the Board. If what you are suggesting that he does not or that there is some other internal operational problem with the Board, please make that clear. 

Just to be clear: If you are asserting that there is some kind of internal problem with the Board, please make that clear and I will take it up with the board.  

--dmm


What I know is that the document I have, TSC_policy.doc, was forwarded most recently by Inder (when he asked about our progress) and I forwarded it to tsc@lists. 

I don't actually know if these are actually the case, or just the vagaries of differing reports, but I wanted to raise it
to your attention.

Ed

Again, if you are dissatisfied with the operation of the TSC or if there other operational problems please use the TSC list to discuss these concerns going forward. IMO this is not a crisis and we're just working out the kinks in how we operate; again if you feel differently please raise it during our call.

BTW, citing unamed sources is considered poor form, so please consider this going forward.


--dmm


 




Re: Possible board/tsc communication breakdown

David Meyer <dmm@...>
 



On Thu, Apr 25, 2013 at 7:39 AM, Ed Warnicke (eaw) <eaw@...> wrote:
I was simply seeking clarification as you sit on both the TSC and board meetings and could thus speak directly :)

Everything is new and moving fast :)


Sure :-) 

Just wanting everything (including communications such as these) to be in the open. In addition, I want to establish that *anyone* can open such a thread on tsc@lists.

--dmm
 
Ed

On Apr 25, 2013, at 9:33 AM, "David Meyer" <dmm@...> wrote:



On Thu, Apr 25, 2013 at 7:19 AM, David Meyer <dmm@...> wrote:


On Thu, Apr 25, 2013 at 6:57 AM, Ed Warnicke (eaw) <eaw@...> wrote:
Dave,
        I've had two things bubbling back to me about board/tsc communication that concern me:

1)  It's been reported to me that our original feedback to the board on the scope did not actually make it
to the board.

I told Inder that we had more extensive edits (as evidenced by, for example, Rob's comments this morning) to the document and I wanted to wait until we had all of the input  incorporated into one package before we gave it to the board. The theory here is that I didn't want to send several drafts with different edits to the board. If you think this should have been handled differently, please raise it on the call.

2)  It's been reported to me that the draft before us was not actually sent to us by the board, but rather unilaterally
        by the chair, not incorporating board feedback.

BTW, in re-reading 2) I'll just note that I consider Inder to speak authoritatively for the Board. If what you are suggesting that he does not or that there is some other internal operational problem with the Board, please make that clear. 

Just to be clear: If you are asserting that there is some kind of internal problem with the Board, please make that clear and I will take it up with the board.  

--dmm


What I know is that the document I have, TSC_policy.doc, was forwarded most recently by Inder (when he asked about our progress) and I forwarded it to tsc@lists. 

I don't actually know if these are actually the case, or just the vagaries of differing reports, but I wanted to raise it
to your attention.

Ed

Again, if you are dissatisfied with the operation of the TSC or if there other operational problems please use the TSC list to discuss these concerns going forward. IMO this is not a crisis and we're just working out the kinks in how we operate; again if you feel differently please raise it during our call.

BTW, citing unamed sources is considered poor form, so please consider this going forward.


--dmm


 




Re: Possible board/tsc communication breakdown

Ed Warnicke (eaw) <eaw@...>
 

I was simply seeking clarification as you sit on both the TSC and board meetings and could thus speak directly :)

Everything is new and moving fast :)

Ed

On Apr 25, 2013, at 9:33 AM, "David Meyer" <dmm@...> wrote:



On Thu, Apr 25, 2013 at 7:19 AM, David Meyer <dmm@...> wrote:


On Thu, Apr 25, 2013 at 6:57 AM, Ed Warnicke (eaw) <eaw@...> wrote:
Dave,
        I've had two things bubbling back to me about board/tsc communication that concern me:

1)  It's been reported to me that our original feedback to the board on the scope did not actually make it
to the board.

I told Inder that we had more extensive edits (as evidenced by, for example, Rob's comments this morning) to the document and I wanted to wait until we had all of the input  incorporated into one package before we gave it to the board. The theory here is that I didn't want to send several drafts with different edits to the board. If you think this should have been handled differently, please raise it on the call.

2)  It's been reported to me that the draft before us was not actually sent to us by the board, but rather unilaterally
        by the chair, not incorporating board feedback.

BTW, in re-reading 2) I'll just note that I consider Inder to speak authoritatively for the Board. If what you are suggesting that he does not or that there is some other internal operational problem with the Board, please make that clear. 

Just to be clear: If you are asserting that there is some kind of internal problem with the Board, please make that clear and I will take it up with the board.  

--dmm


What I know is that the document I have, TSC_policy.doc, was forwarded most recently by Inder (when he asked about our progress) and I forwarded it to tsc@lists. 

I don't actually know if these are actually the case, or just the vagaries of differing reports, but I wanted to raise it
to your attention.

Ed

Again, if you are dissatisfied with the operation of the TSC or if there other operational problems please use the TSC list to discuss these concerns going forward. IMO this is not a crisis and we're just working out the kinks in how we operate; again if you feel differently please raise it during our call.

BTW, citing unamed sources is considered poor form, so please consider this going forward.


--dmm


 



Re: Feedback on singularity text for TSC Policy document

David Meyer <dmm@...>
 


Rob,


On Thu, Apr 25, 2013 at 7:36 AM, Rob Sherwood <rob.sherwood@...> wrote:
Also, IIRC, Chris and Ed were going to have feedback on the 2nd section of the document.  Is it possible to get example text or general thoughts about it posted before the call so we can try to have a more focused conversation?  I realize we only have a few hours, but even a few minutes of time to read the text might be useful.

I have asked Ed and Chris for their feedback. Hopefuly we'll see that RSN :-)

--dmm
 
- Rob
.


On Thu, Apr 25, 2013 at 7:22 AM, David Meyer <dmm@...> wrote:
This is the first topic for our call today. We have to complete our feedback for the board this week.

--dmm


On Thu, Apr 25, 2013 at 3:57 AM, Thomas Nadeau <tnadeau@...> wrote:

This is definitely worth discussing on the next call.  

--Tom


From: Rob Sherwood <rob.sherwood@...>
Date: Wednesday, April 24, 2013 4:56 PM
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] Feedback on singularity text for TSC Policy document

Hi TSC folks and all,

I just wanted to start this thread to try to get some feedback before the TSC meeting.  I took the action to suggest updated text for the Singularity part of the draft TSC policies document.

The originally proposed text says:

------

The following relate the projects initiated by the TSC and the artifacts created therein.

·      Singularity:  To the extent possible, there should be  no overlap between the goals of the mature projects and artifacts created by them

·      Cohesiveness:  The artifacts created within each mature project should connect appropriately to other mature/core projects to form a cohesive system.  (It is understood that this will not apply to artifacts that are  stand-alone by design)

-------

Before I settle on the updated text, I wanted to suggest the following policy and get feedback on it.

In my mind, given not only do we have some overlap in the controller space, but as more network virtualization projects start to land (e.g., Dove from IBM, the proposed contribution from NEC) we will have even more overlapping code in the near future.  So, in other words we will likely need some sort of staged strategy for resolving the overlap and incentives for doing so in a timely manner.

So specifically my proposal is:

1) For bootstrap and incubation stages, allow overlapping code bases.

2) In order to get to the 'mature' state, there has to be an agreed upon plan (by all affected projects) for how to merge all of the code into a single code base.

3) In order to get into the 'core' state, the code has to be successfully merged (read: there can only be one core project of any one piece of functionality)

Does this make sense?  I think this tracks both with people's expectations (in that we should be working to remove overlap) as well as the current reality (we have a bunch of overlapping code without a plan or incentive for how quickly we need to resolve the overlap).  By using the 'mature' state as a "do you at least have a plan" state and the 'core' state as "did you successfully execute that plan" I feel like there are reasonable steps towards incremental progress in place.

I'm hoping this is the best of both worlds, but I'm open to feedback,

- Rob
.


_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc





Re: Feedback on singularity text for TSC Policy document

Rob Sherwood
 

Also, IIRC, Chris and Ed were going to have feedback on the 2nd section of the document.  Is it possible to get example text or general thoughts about it posted before the call so we can try to have a more focused conversation?  I realize we only have a few hours, but even a few minutes of time to read the text might be useful.

- Rob
.


On Thu, Apr 25, 2013 at 7:22 AM, David Meyer <dmm@...> wrote:
This is the first topic for our call today. We have to complete our feedback for the board this week.

--dmm


On Thu, Apr 25, 2013 at 3:57 AM, Thomas Nadeau <tnadeau@...> wrote:

This is definitely worth discussing on the next call.  

--Tom


From: Rob Sherwood <rob.sherwood@...>
Date: Wednesday, April 24, 2013 4:56 PM
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] Feedback on singularity text for TSC Policy document

Hi TSC folks and all,

I just wanted to start this thread to try to get some feedback before the TSC meeting.  I took the action to suggest updated text for the Singularity part of the draft TSC policies document.

The originally proposed text says:

------

The following relate the projects initiated by the TSC and the artifacts created therein.

·      Singularity:  To the extent possible, there should be  no overlap between the goals of the mature projects and artifacts created by them

·      Cohesiveness:  The artifacts created within each mature project should connect appropriately to other mature/core projects to form a cohesive system.  (It is understood that this will not apply to artifacts that are  stand-alone by design)

-------

Before I settle on the updated text, I wanted to suggest the following policy and get feedback on it.

In my mind, given not only do we have some overlap in the controller space, but as more network virtualization projects start to land (e.g., Dove from IBM, the proposed contribution from NEC) we will have even more overlapping code in the near future.  So, in other words we will likely need some sort of staged strategy for resolving the overlap and incentives for doing so in a timely manner.

So specifically my proposal is:

1) For bootstrap and incubation stages, allow overlapping code bases.

2) In order to get to the 'mature' state, there has to be an agreed upon plan (by all affected projects) for how to merge all of the code into a single code base.

3) In order to get into the 'core' state, the code has to be successfully merged (read: there can only be one core project of any one piece of functionality)

Does this make sense?  I think this tracks both with people's expectations (in that we should be working to remove overlap) as well as the current reality (we have a bunch of overlapping code without a plan or incentive for how quickly we need to resolve the overlap).  By using the 'mature' state as a "do you at least have a plan" state and the 'core' state as "did you successfully execute that plan" I feel like there are reasonable steps towards incremental progress in place.

I'm hoping this is the best of both worlds, but I'm open to feedback,

- Rob
.


_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc




Re: Possible board/tsc communication breakdown

David Meyer <dmm@...>
 



On Thu, Apr 25, 2013 at 7:19 AM, David Meyer <dmm@...> wrote:


On Thu, Apr 25, 2013 at 6:57 AM, Ed Warnicke (eaw) <eaw@...> wrote:
Dave,
        I've had two things bubbling back to me about board/tsc communication that concern me:

1)  It's been reported to me that our original feedback to the board on the scope did not actually make it
to the board.

I told Inder that we had more extensive edits (as evidenced by, for example, Rob's comments this morning) to the document and I wanted to wait until we had all of the input  incorporated into one package before we gave it to the board. The theory here is that I didn't want to send several drafts with different edits to the board. If you think this should have been handled differently, please raise it on the call.

2)  It's been reported to me that the draft before us was not actually sent to us by the board, but rather unilaterally
        by the chair, not incorporating board feedback.

BTW, in re-reading 2) I'll just note that I consider Inder to speak authoritatively for the Board. If what you are suggesting that he does not or that there is some other internal operational problem with the Board, please make that clear. 

Just to be clear: If you are asserting that there is some kind of internal problem with the Board, please make that clear and I will take it up with the board.  

--dmm


What I know is that the document I have, TSC_policy.doc, was forwarded most recently by Inder (when he asked about our progress) and I forwarded it to tsc@lists. 

I don't actually know if these are actually the case, or just the vagaries of differing reports, but I wanted to raise it
to your attention.

Ed

Again, if you are dissatisfied with the operation of the TSC or if there other operational problems please use the TSC list to discuss these concerns going forward. IMO this is not a crisis and we're just working out the kinks in how we operate; again if you feel differently please raise it during our call.

BTW, citing unamed sources is considered poor form, so please consider this going forward.


--dmm


 


14281 - 14300 of 14349