Steering Committee Minutes 2007-06-28
From MemberWiki
URL: http://www.openajax.org/member/wiki/Steering_Committee_Minutes_2007-06-28
(These minutes have not yet been approved by Steering Committee vote.)
Contents |
OpenAjax Alliance Steering Committee meeting minutes 2007-06-28
Attendees
- IBM/David Boloker
- ZEND/Michael Pinette
- TIBCO/Kevin Hakman
- ZIMBRA/Scott Dietzen
- DOJO/Alex Russell
- Jon Ferraiolo
Original Agenda
- Agenda
- "Members in good standing"
- Proposed update to Development Process: http://www.openajax.org/member/wiki/Development_Process_v2
- The comments at the top of the above wiki page summarize the changes. I have copied/pasted that change summary here:
- Increase the number of days for working group proposal review from 5 days to 10 days
- Clarify that the Working Group Chair must determine if there is consensus within the Working Group that Material (such as Specifications) before deciding whether to advance the given Material for subsequent process steps (e.g., Release Review, member voting, and Steering Committee voting)
- Add definition of "Working Group Members in Good Standing", along with implications on voting procedures within a Working Group
- Minor editorial cleanups
- Individuals as members
- What should we do in response to iPhone?
- Blog? Push hard for Apple membership?
- Building momentum about mashup security
- Yahoo/Doug Crockford has created a [caplets] mailing list on the topoic
- Subspaces proposals from MS and Stanford
- More recently, <FRIV> proposal from MS and Stanford
- IBM has an internal paper on the subject, determining if OK to go public
- (NEW TOPIC) Jon's ideas on 2 blog postings
- The 2 topics:
- OpenAjax Principles - (1) we look for solutions that work with today's browsers (vs. W3C/WhatWG who are defining specs for tomorrow's browsers) with APIs likely to work well once W3C/WhatWG specs finally are approved and ship, (2) simultaneous open source and specs, (3) vision for use of Ajax (i.e., browser technologies) beyond the browser (e.g., widgets). (Any others?)
- Vision for Hub 1.1 - Adds CommHub (i.e., Comet) and SecurityHub. Supports secure cross-frame communications and secure client-server communications, including server push.
- Process
- First, Jon develops a draft within a personal wiki page
- Then send note to Marketing WG asking if anyone sees a problem for posting on OpenAjax blog
- If OK, then post on OpenAjax blog
- The 2 topics:
- Status reports on activities (Marketing WG, Interop WG, IDE TF, Comm Hub TF, Security TF, Mobile TF, Performance TF)
- "Members in good standing"
Minutes
Topic: "Members in good standing" and proposed updated Development Process
(Jon gives background that led up to this proposal and explains what we are trying to accomplish. First, simple change as we agreed to increase period of review for WG creation proposals from 1 week to 2 weeks. Then, clarification of things that were implicit before about Chair having responsibility for particular working group activities. Finally, the introduction of the concept of a Working Group Member in Good Standing. Only matters for formal votes, such as advancing a Specification for future member vote and SC vote. Two things this accomplishes. First, better defines the process for how WGs work. Second, encourages participants to come to meetings and participate in discussions for fear they might fall out of good standing.)
MikeP: Seems reasonable.
(Jon explains further that the Chair will need to maintain a list of members and make sure the good standing list is up to date before any votes are taken.)
Kevin: The language has fuzziness, probably on purpose. Probably better to include a sentence that says that someone who is not in good standing can appeal to the SC.
Jon: Makes sense to me.
Kevin: Otherwise, we would have to have a firm definition of exactly what it means to be in good standing and I wouldn't want to go down that path.
Jon: Any disagreements with Kevin's proposed change?
(none)
Jon: Rephrase, anyone object to unanimous agreement?
(none)
Jon: Any other comments?
(none)
Jon: So, I propose to change the write-up to include Kevin's suggestion and then send to members for +1/-1 opinions on whether the SC should approve.
Kevin: Sounds good.
(Alex joins at this point. Jon repeats prior discussion.)
Alex: This proposal says that the list of members in good standing has to be published before a vote?
Jon: Yes. That probably means we would need to add a period like a week where people were notified that they were not in good standing so that they could appeal.
Kevin: Maybe better to say that the list of members and members in good standing have to be kept up to date.
Jon: Yes, that's better. Chair has to maintain a list of members in good standing. Whenever a member falls out of good standing, chair needs to tell them.
Alex: But what's the win with members in good standing?
Jon: Two things. On procedural front, makes sure that people who are involved in formal votes have been active in discussions, thereby preventing trouble by companies who are more interested in preventing progress and just want to pop in occasionally to stall things. But this started mainly for motivational reasons for people to show up regularly.
Kevin: Origin of this member in good standing was partly to increase participation. For example, there are about 20 companies in the IDE task force but only 4-6 organizations show up regularly. Want to increase levels of involvement.
Alex: That's different than wanting to fix the voting process.
Kevin: Yes, but it does say that you can participate in voting only if you are a consistent participant.
Jon: Promotes guilt.
(personal statements about people's tendencies to feel guilty easily)
Alex: OK as a social hack.
Jon: Any objections to unanimous approval to fix and then send to members for voting?
(none)
RESOLUTION: Jon to fix per Kevin's suggestion and then send to participants@openajax.org for member voting.
Topic: Proposal for allowing individuals to join OpenAjax Alliance
(Jon explains background. We talked about this a couple of meetings ago. We decided to be careful and conservative regarding IP issues and thus require an employer consent form. As instructed, Jon went off to work out exact wording, with help from an IBM lawyer who is not advising OpenAjax Alliance but making helpful suggestions about how things are constructed and worded.)
Jon: We have chosen a middle ground between two extremes, where one extreme makes it reasonable and convenient for individuals to join, and the other extreme where we require their employers to join OpenAjax Alliance. This middle ground is likely to prove as burdensome for some individuals as asking their employers to join. It is likely to be as difficult for some people to get their employer to sign a consent form as it is to sign the members agreement. But for individuals who are not employed by a company, this process is probably OK. We have at least one person in the queue who falls into this category.
Kevin: Have we test-marketed this with some individuals? Don't want an adverse reaction.
David: Has everyone on the phone looked at it? Remember, this onerous process is the result of our IP concerns.
Alex: At Dojo, we trust individuals to take care of things with their employers and put the burden on them. I agree that this proposed process is almost as onerous as the full process.
David: Yes, for mid- and big-size companies, maybe as onerous, but people who are not employed or work for small companies, this will be easier.
David/Alex: The problem with mid- and large-size companies is that there is likely to be an employment agreement.
Jon: (In response to Kevin's earlier question about test-marketing) John Resig of JQuery was one of the complainers about how we don't have a good process for individuals and my guess is that he is unlikely to like this proposed method. However, people who are on their own or work for small companies will probably just do what the process tells them to do without complaining.
Kevin: How about Doug Crockford and json.org versus Yahoo?
Alex: He must have gotten some permission.
David: Our other choice is to take on IP risk, but that's a formidable risk.
Alex: Let's be clear. Our goal is to mitigate risk, but we aren't trying and can't eliminate risk. What if we just had individuals agree to take on the burden of responsibility?
David: We are just asking to have employers sign a paper that says they know about their employees activities in OpenAjax.
Alex: We want to maximize likelihood of good behavior and minimize impact from bad behavior.
Scott: Anything we can learn from other orgs, like Eclipse and JCP?
Jon: This process is based on Eclipse. In fact, MikeM mailed me the Eclipse consent form. I replace the Eclipse logo with an OpenAjax logo and then worked with the IBM lawyer on tweaking the text to make it appropriate for us.
David: (Doing real-time online research) JCP has a separate agreement for individuals. Individual agrees not to share information with their employer. At the end is an Exhibit B, which is a 12-page doc. On the last page is a waiver form that their employers have to sign.
Scott: In general, Eclipse gets high marks for their process.
Jon: While this process is conservative and corporate, I think we can justify it to the community on the basis of us being careful about IP for the benefit of the community to maximize their safety using the technologies produced out of OpenAjax Alliance.
Jon: Anyone disagree with unanimous approval to send to the members for review and +1/-1 voting?
(no disagreement)
Jon: OK, I will send this to the members, but only after the revised Development Process. Too confusing for members to have two topics on the table at once.
RESOLUTION: Jon to send proposed process on individuals-as-members to members for review and vote, but after Develop Process settles down.
Topic: What show we do differently given the iPhone
(Acknowledgement about how great it is that the iPhone uses Ajax exclusively as their developer platform, how nice many of the features are, how it is likely an industry changing event such that 3.5G+WebKit+H2.264 becomes the standard mobile platform, and how its impact might be strong in ways we can't predict today. Discussion about how we would very much like Apple to join OpenAjax Alliance, but in engaging them on getting involved, we speculated that their likely interest in short-term is to improve their device by adding features in a standards-compliant manner and attracting interest in their device rather than an overriding priority to help the Ajax ecosystem.)
(out of time)
Topic: Next meeting
(We decided Friday July 13 11AM PT, 2pmET)
