Date   

Re: agenda item for next call

David Meyer <dmm@...>
 

Sure, thanks for the suggestion. Phil, can you add that near the top of list? Thanks, --dmm


On Wed, Apr 24, 2013 at 12:54 PM, Chris Wright <chrisw@...> wrote:
I'm not sure where we ended on the "one repo per project" discussion.
Can we be sure to allocate some time to finish that discussion?

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


Updated Invitation: OpenDaylight TSC Meeting @ Thu Apr 25, 2013 11am - 12pm (probb@linuxfoundation.org)

Phil Robb
 

This event has been changed.

OpenDaylight TSC Meeting

Changed: OpenDaylight Technical Steering Committee meeting.

Please hold this time for the weekly OpenDaylight TSC meeting.

Date and Time: Thursday, April 25, 2013 10:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Event number: 663 405 259
Event password: odptsc
Event URL for attendees: https://linuxfoundation.webex.com/linuxfoundation/onstage/g.php?d=663405259&t=a

Teleconference Information:
US TOLL: +1-415-655-0001
Access code: 663 405 259

Meeting Agenda
To see the meeting agenda, please visit https://wiki.opendaylight.org/view/TSC:Main

When
Thu Apr 25, 2013 11am – 12pm Mountain Time
Where
+1 415-655-0001 : Access code 663 405 259 (map)
Calendar
probb@...
Who
(Guest list is too large to display)

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account tsc@... because you are an attendee of this event.

To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.


Re: agenda item for next call

Phil Robb
 

Done.

Phil.


On Wed, Apr 24, 2013 at 10:56 AM, David Meyer <dmm@...> wrote:
Sure, thanks for the suggestion. Phil, can you add that near the top of list? Thanks, --dmm


On Wed, Apr 24, 2013 at 12:54 PM, Chris Wright <chrisw@...> wrote:
I'm not sure where we ended on the "one repo per project" discussion.
Can we be sure to allocate some time to finish that discussion?

thanks,
-chris
_______________________________________________
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


Feedback on singularity text for TSC Policy document

Rob Sherwood
 

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
.


agenda item for next TSC

Chris Wright <chrisw@...>
 

board requests us to nominate a TSC liason to the marketing committee.
i agreed to bring this to the TSC as an agenda item.

thanks,
-chris


Re: Feedback on singularity text for TSC Policy document

Thomas Nadeau <tnadeau@...>
 


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
.


Re: Possible board/tsc communication breakdown

David Meyer <dmm@...>
 



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.

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@...>
 

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: agenda item for next call

David Meyer <dmm@...>
 



On Wed, Apr 24, 2013 at 9:54 AM, Chris Wright <chrisw@...> wrote:
I'm not sure where we ended on the "one repo per project" discussion.
Can we be sure to allocate some time to finish that discussion?

BTW, while we need to come to "closure" on that topic, as I mentioned on a previous thread we need to finish up our work on TSC_policy.doc and get that to the Board. To that end, I want to take up TSC_policy first and work through that before we take on the other agenda items.

--dmm
 

thanks,
-chris
_______________________________________________
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


 



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: 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: 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: 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@...>
 

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


 




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


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
.


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”


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


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


41 - 60 of 14240