BPEL4People TC - Which Accepted Issues to Work On?

[Dave Ings <ings@ca.ibm.com>]

As your neutral chair I will of course abide by the TC's collective wisdom. :-)

However in my view there are two overlapping but distinct questions to resolve: (1) in what setting does the work to create draft resolutions get done and (2) who does the work. I think our collaboration model need to address both. So while email and triage notions expressed below are worthwhile, IMHO they address (1) more than (2).

I look forward to the discussion at this week's TC!

Regards, Dave Ings,
Emerging Software Standards
Email: ings@ca.ibm.com
Yahoo Messenger: dave_ings
----- Forwarded by Dave Ings/Toronto/IBM on 2008/05/12 10:27 PM -----

From:	Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>
To:	Mark Ford <mark.ford@activevos.com>
Cc:	Dave Ings/Toronto/IBM@IBMCA, bpel4people@lists.oasis-open.org
Date:	2008/05/12 09:50 PM
Subject:	Re: [bpel4people] BPEL4People TC - Which Accepted Issues to Work On?

---

Mark,

+1. Con-call and F2F time should be focused on the really tough issues, where we need to utilize the higher bandwidth and synchronous nature of "live" communication (voice & visual). In addition, email works as a way of "setting the stage" for some issues, allowing the whole TC to get up to speed on the details (and complexities) of a particular issue. 

I was part of the WS-BPEL TC from the start, and I'm sure it lasted more than 12 years. :-) I particularly recall that we took about three years to resolve issue 11. There were several failed attempts to solve that issue, and the email record helped form a type of institutional memory for the TC, so that we avoided retrying previous solutions. It also helped new folks get up to speed on many of our "chronic" issues, as you experienced. I sincerely hope we won't take so long on the current specs!

I think we should save the "form a subcommittee" move for when it is appropriate. If we discover a fair-sized chunk of the spec is of interest to only a few members of the TC, it may speed things up to form a subcommittee to consider it in parallel with the main TC's work. We shouldn't embrace this as a standard issue-solving strategy. I'm not sure anything in BPEL4People and WS-HT will qualify for subcommittee treatment under this sort of rule, but I could be wrong.

--Ron

On May 12, 2008, at 15:36 PM, Mark Ford wrote:

My preference is to use email for resolving issues instead of saving this work for the conference calls or face to face meetings. While work in conference calls and face to face meetings can be very productive, it doesn't leave a good permanent record regarding the thought process behind issue resolution. I came to the WS-BPEL spec late (I think it was year 7 of what ended up being a 12 year TC) and there were more than a few issues that I was better able to understand by pouring through the email exchanges.

I don't like the idea of forming subsets of the TC to work on issue proposals. This work should be done on the email list. If members want to privately bounce ideas off of other TC members then they are free to do that, but I don't want to formalize this with subsets of the TC.




---

From: Dave Ings [mailto:ings@ca.ibm.com]
Sent: Monday, May 12, 2008 11:57 AM
To: bpel4people@lists.oasis-open.org
Subject: [bpel4people] BPEL4People TC - Which Accepted Issues to Work On?


Regarding the draft agenda for this week's B4P TC, in addition to discussing the two items forwarded below, I would like to propose that the remainder of the meeting be a working session to begin to develop proposals for previously accepted issues.

So I would like to seek suggestions as to which (say) 2-3 accepted issues would be appropriate to add to this week's agenda.

Regards, Dave Ings,
Emerging Software Standards
Email: ings@ca.ibm.com
Yahoo Messenger: dave_ings
----- Forwarded by Dave Ings/Toronto/IBM on 2008/05/12 11:51 AM -----


<ecblank.gif> From:	<ecblank.gif> Dave Ings/Toronto/IBM
<ecblank.gif> To:	<ecblank.gif> bpel4people@lists.oasis-open.org
<ecblank.gif> Date:	<ecblank.gif> 2008/05/08 05:28 PM
<ecblank.gif> Subject:	<ecblank.gif> Next B4P TC Meeting - Two Discussion Topics

---



Hi,

I wanted to seed the TC with two topics for discussion at the next TC. Comments to the list in advance of the meeting are of course welcome!

1. First TC F2F

During a previous TC we agreed to tentatively schedule our first F2F in Walldorf (Germany) the week of June 9th, and that we'd make a final decision in mid-May. Given the issues list is now primed, I think we could have a productive F2F, with main meeting goal to be to work all the open issues and come up with proposed resolutions. A secondary (but very important!) goal would be to continue to build team spirit and working relationships.

I have conferred with SAP (who has agreed to host) and if the TC so decides we could run the F2F from noon Monday June 9th through noon Wednesday 11th. The noon to noon arrangement will minimize travel disruption. Note that while it will be possible to participate by phone, it will be more effective to be there in person.

Finally, the meeting will need to achieve quorum to be effective. Could voting members come to the 5/14 TC prepared to let me know whether they intend to participate in person (assuming the TC votes to confirm the meeting). We currently have 26 voting members.

2. Collaboration Model

Hats off to Mark Ford and the rest of the Editor's SC for priming our issues list and getting us going. The next question we face as a team is what is the right collaboration model(s) to develop issue resolution proposals?

We could develop all proposed resolutions in "group mode" in TC meetings and/or in the F2F. While this is very democratic <g> like democracy it isn't always the most effective approach.

We could ask for volunteers, or small teams of volunteers, and "assign" individual issues to them, to develop a resolution "offline" followed by discussion and review with the full TC.

Or we could go with some blend of the above, perhaps predicated on the contentiousness or scope of the issue.

Note that I am only suggesting how a *draft* issue resolution might be developed. The full TC always has to review and approve any resolution prior to it being assigned to the Editing SC for incorporation into the spec.

Regards, Dave Ings,
Emerging Software Standards
Email: ings@ca.ibm.com
Yahoo Messenger: dave_ings