CF: Incubation is the first step.
ST: There was a proposal… we worked on this during hackathon. At this point, we move to incubation.
MD: We shouldn’t be gateing and creating barriers for getting incubation and ideas to start. This is different than a standards effort. Others are free to bring proposals as well. This method is similar to every major open source project.
HM: May be a matter of semantics. Need to make code easier to use. Shouldn’t be wedded to a single architecture. People seem to agree on what we need to do, but maybe arguing about terminology.
MB: This is not _the_ codebase. This is _a_ codebase that will be evaluated at a future point. Want to understand what this evaluation will entail and what efforts are setting this criteria? Lastly, feels like proposal is code without an understanding exactly what it is being proposed. Architecture is extremely high level… want to understand how these components will be deployed, made available, etc. What is being proposed architecturally? That said, in favor of making code work, in parallel.
CF: We need to aggressively work on evaluation criteria. We can make that part of the proposal. That said, we need to get code into the HLP project that everyone can start collaborating on. If someone else wants to do a proposal that we incubate side-by-side, it is welcomed!
SL: What are we accepting? Maybe we accept parts of architecture and break into separate projects? Right now it seems we are accepting entire OBC architecture as a proposal
CF: This is a place to start from, not an end result.
RGB: Struggling to understand how to contribute to process. It is becoming clear that he needs to understand what we think an end state could be. I disagree that there will ever be one correct codebase… different architectures for different requirements. If the intention is that we get to one codebase, then we need to agree on the problem we are trying to solve. Or, if the vision is that there are several sister projects addressing needs, that is possible too. When we talk about eval process, need to address this.
CF: May be a problem of semantics. We are not selecting a code base. Requirements, use cases, etc. will all shape what we build. This is like starting with a lump of clay. Just want to start a process of getting people to collaborate and working together.
Murali: In favor of merging code bases. Maybe we come up with a target architecture and identify different components and note which components come from which proposals.
CF: Yes. Other people may come forward with ideas of better member services (for example)... this is exactly what we want to do. This is just a lump of clay to evolve.
PD: If you have another idea, put a proposal forward. Competing ideas lead to innovation.
CF: OpenStack, for example. Someone may want to refactor a component. Get others to collaborate with them.
EM: Maybe noting that this is one project being moved into incubation, but it is not intended as the _only_ foundation.
CF: Correct. But, people need to bring proposals.
ST: Help us and others understand the initial proposed code… need a 101 description which would help everyone put it on a broader development base.
DV: Sounds like a lot of violent agreement. A lot is semantics. Doesn’t see how moving this to incubation conflicts with any points above or what happens next or someone makes a different suggestion.
TB: There are advantages to this merge. DAH comes from bitcoin angle, IBM comes from more general angle. This is pragmatic merge.
MB: What does accepting proposal mean? 1) we give it a label that it is incubation status. 2) give it a spot on the hyperledger github. What else? What changes?
CF: Bring under HLP umbrella and it goes under the governance of the project. It would be moved from the independent repository. This would put it under governance to engage and accept work from others.
MB: In terms of process, it sounds like the real difference under HLP label, set of guidelines for code review, commitment, licensing, community, contributions, etc.
CF: Successful at hackathon with getting different companies to collaborate. There can be other proposals. But, important that we start engaging and collaborating as community.
CA: How about we accept the proposal into incubation, but make sure there, in this repo, there is further clarity that a) we are hoping for further proposals and incubation projects, that b) this isn't not a base at this time, and c) that as the first in there are incomplete understanding of goal end state and are waiving requirements of the proposal process of having a well defined scope as we don't know scope yet.
ALH: Suffering by lack of common understanding of what it means to be in incubation. Project Lifecycle doc could have solved this. This document needs more work. Need to finalize work of lifecycle doc and publish on web.
ACTION: Christopher Allen and Mic Bowman suggest verbiage for readme for how we characterize this
MD: Need to think in long term. Putting up gates in front end for proposals may create challenges. Focus more on getting out of incubation, as opposed to getting into incubation.
RGB: Good point. This makes the readme clarification important.
Primrose: There are multiple proposals. Why are just IBM, DAH, Blockstream as an incubator? How does Ripple or others become incubating?
MD: Those were statements of proposed contribution. Please put forward a proposal for incubation.
CF: It sounds like people are ok, but stuck on semantics.
RJ: Would be good to have an Architecture WG
Ram will lead the WG, Hart will help.
Ram to circulate note on mailing list with more details and call for volunteers
