> > On Fri, Jul 8, 2016 at 8:15 AM, Gray, Mark D <mark.d.g...@intel.com> wrote: > >> On Wed, Jul 6, 2016 at 9:12 AM, Gray, Mark D <mark.d.g...@intel.com> > >> wrote: > >> > Processes (not really dealt with by the charter but worth some > discussion): > >> > * I think the following would improve transparency, I don't know if this > >> should be in the charter, but I think it would be good to address: > >> > a. A more open roadmap to avoid duplication, encourage > collaboration > >> and avoid disappointment when a lot of work has been put into > something > >> that doesn't get a lot of support from the community. I really liked the > way > >> OVN started, Ben circulated some development documents which gave > >> everyone a good idea of what was going on before code was written and > an > >> opportunity to help out or comment on. You could take this to the > extreme > >> and do something like blueprints in Openstack (but this is probably a too > >> heavyweight?) > >> > b: When the TSC members meet, it would be good that it was > >> documented and shared so we can understand the decision making > process > >> for the technical direction. > >> > > >> > Voting: > >> > * The charter states that "While it is the goal of OVS to operate as a > >> consensus based community, if any TSC decision requires a vote to move > >> forward, the Committers shall vote on a one vote per Committer basis." > >> > Due to b) above, the distribution of the TSC inevitably weighted > towards > >> the Nicira team which effectively gives veto to one group. I believe this > >> is > >> something we should as a community attempt to change. This is obviously > >> not going to happen immediately but if we put the right processes in > place, it > >> should make it easier. One example may be to limit the number of votes > >> allocated to one group? Maybe there are other suggestions? > >> > > >> > * There doesn't seem to be a process to propose a committer unless > you > >> are a committer. Maybe this could change? > >> > >> I think one thing that might be useful for context is that the > >> committers as a group (soon to be TSC) have never discussed or voted > >> on anything other than administrative matters - meaning things like > >> electing new committers and now this transition to the Linux > >> Foundation. There aren't any meetings where roadmaps are planned or > >> otherwise decide on anything related to technical direction - all of > >> that would take place on the public mailing list. In that light, > >> anyone can send out proposals for roadmaps, etc. to the mailing list > >> in the same way that anyone can submit patches. (And there actually > >> isn't much advantage to being a committer - a committer better not be > >> applying patches that haven't been reviewed or aren't supported by the > >> community.) > > > > Actually, I didn’t think that you guys did discuss other matters. However, I > think > > that this is a gap. I think it would be beneficial to have a better > understanding of > > what contributors are working on or are thinking of working on as it > > may help encourage collaboration early in the design phase of features and > > get early feedback. > > > > Again, this is more related to process than the charter but I would > > encourage the TSC to look at these processes. Also, on the subject of > process > > a bug tracking database of some description may be useful. I'm sure the > > Linux Foundation could provide the infrastructure for this. > > Just one quick note on the bug tracker - there actually is one already > as part of the OVS project in github > (https://github.com/openvswitch/ovs-issues/issues). It's mostly used > by the Windows guys but I think that if more people started using it > then more developers would start looking at it carefully.
Good point. We should look at using that more. I will have a chat to the folks here. > > I agree that the development process is probably separate from what > goes into the charter but it's absolutely important to discuss how we > can improve things. The main thing is likely how to balance any > processes with what I think is a pretty strong desire to keep things > lightweight. I actually really would encourage people to send > development plans/proposals to the mailing list in advance - I know > that some open source communities only want to see code but my feeling > is that people here are pretty open to giving comments on proposals. :D Completely agreed on the light-weight!!! Yes, it is good to see working code but sometimes it’s a lot quicker to jot down ideas in plain-text and get quick feedback from the community so that a developer doesn’t end up going down a complete dead end. There is a lot of expertise in the community that could be used early to help prevent this. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss