Yeah that makes an awful lot of sense. In that case, I think its a great idea. I'm in.
-J On Sun, Jun 23, 2013 at 6:27 PM, Michael MacFadden <[email protected]> wrote: > 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" <[email protected]> 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 >><[email protected]> 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 > >
