Joseph, I think I should make it clear that the committee has absolutely no authority. A committer does not have to check with a committee to commit something or to make a change. The committee gets no special voting rights. The only idea of the committee is to have 2-5 people who commit to making sure we advance discussion on the mailing list, and then record the major design decisions results in a wiki page.
Anyone can participate in the discussions. And any one can contribute. The committee is simply there to facilitate discussion on an important topic and to make sure we make progress. Furthermore, committees can be ephemeral. Meaning if we have something that needs attention right now, we can form a committee, then later when that has been resolved we can dissolve the committee. When a new topic arises we can form a new committee. The whole reason for doing this is that we have a lot of discussion going on now in the list, but most of it wanders all over the place, and not much actual decision making has happened. I think that forming a committee that ensures we set objectives, have discussions, and make decisions in a focused and timely manner will help. But as I said in no way do these people become gate keepers and people would not need permission from the committee. They are just volunteers who agree to help move the conversation along. Does this make more sense? ~Michael On 6/23/13 4:54 PM, "Joseph Gentle" <jose...@gmail.com> wrote: >These are the steps I think we should take around the new federation >protocol: > >1a. Figure out a p2p-capable OT algorithm & design that we're all >happy with. Make an in-process proof-of-implementation & randomizer to >convince myself its correct & not horrendously slow. > >1b. Decide what data structure we want for waves. (See thread: 'A Very >Wavey Plan') > >2. Implement (1) in a way that allows two processes to share a >document via OT. This will require figuring out a really simple >unauthenticated federation protocol. I expect to first get this >working for plaintext documents, then swap over to the wave data model >once we have decided on a data model and written transform (&etc) >functions for it. > >3. Decide what kind of encryption to use for operations & documents, if >any. > >4. Either / both of: >- Port the new code & concepts to WIAB. >- Add encryption, access control and a database to the proof of >implementation written in step 2. (I want a second compatible >implementation of wave written in !java) > > >For OT, we need to deep dive on algorithms with people who are well >read & know our options. For that, it would make sense to have a >working group to define the problem & discuss solutions. But when it >comes to actually coding it, I don't actually want input from >non-contributors. If etting your permission will only slow us down. > >I guess the advantage of forming groups around the other issues is >that it gives people autonomy around making decisions and changes. >However, I worry that if committee groups aren't made up of actual >contributors, they'll simply add another hoop for contributors to jump >through before making meaningful changes to the code. Eg, if Ali and >Yuri decided they didn't like GYP, they shouldn't need permission from >anyone to fix it. And I also don't want non-committers telling them >not to. > >So I guess, I'm happy to form committees so long as their purpose is >to move the project forward, not simply make recommendations for other >people to implement. > >-J > >On Sun, Jun 23, 2013 at 3:24 PM, Michael MacFadden ><michael.macfad...@gmail.com> wrote: >> Wavers, >> >> Apache is an open community and a do-ocracy. We don't have a >>hierarchical structure and anyone is welcome to contribute in any way >>they wish. This is a key principle of being an Apache project. >> >> At the same time we need to start to have focus in several key areas in >>order to progress. As such I am recommending we for sever committees >>with focused topics of discussion, specific goals, and plans of action. >>The committees are not intended to be exclusive in any manor. Discussion >>will happen on the dev list where everyone is welcome to participate. >>Rather the point of the committee is to give some focus to a group of >>developers who agree to help advance particular aspects of Apache Wave. >>These members would commit to facilitating discussion on certain aspects >>of wave. >> >> I propose we form four committees based on my observation of the wave >>project. >> >> 1. Operational Transformation >> Research and design of OT algorithms, data models, and concurrency >>control. >> >> 2. Protocols >> Investigate protocols such as federation, client server, and the >>underlying mechanisms such as protocol transport and discovery. >> >> 3. Development, Build (eg maven) and Release >> This committee would focus on making wave easier to develop, build, and >>release. This can include documentation, architecture diagrams, maven, >>git, etc. this will hopefully help attract developers to the project. >> >> 4. Client / Server Architecture >> This last group would leverage the work of the first three to start to >>separate the client and server components. >> >> The vision would be that the committees would start holding regular >>discussions and start to document plans and decisions in sections of the >>wiki. >> >> I would like your thoughts on the formation of committees, if we have >>the right ones identified, and if there is interest in supporting this >>model. >> >> Regards, >> >> Michael MacFadden >> http://www.macfadden.org
