It's perhaps superficial, but if you call these "working groups" then perhaps that takes away some of the hoop-jumping perception. These are sub-communities which try to attract people who can help to solve specific problems. I like the scheme.
On Joseph's point 1a, I think that it would be acceptable if we discovered a relatively low performance threshold for P2P Wave. The "Waving by wandering around" model is likely to have relatively few participants in any given instance, and a well-packaged server could be invited into a conversation easily. Jblossom On Sun, Jun 23, 2013 at 11:52 PM, Joseph Gentle <jose...@gmail.com> wrote: > 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 > <michael.macfad...@gmail.com> 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" <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 > > > > >
