> 
> 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

Reply via email to