Community & Committing rules

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Community & Committing rules

Stephan Ewen
Hi!

I think part of the discussion that arose around the proposed Java/Scala
and RPC/Akka changes comes from the fact that we have not clearly written
down the community/committing rules anywhere yet. In particular, how do we
treat proposed major changes.

Most of us (including me) worked under the assumption that committers can
commit small fixes immediately, and those can be vetoed (reverted) in
hind-sight by others (has not yet happened, though).

Anything that has impact on other people goes through pull requests, and is
then discussed upon, revised, or rejected. This seems to be the model that
many other Apache projects use (like Mahout for example, Sebastian, correct
my if I am wrong there).

That has seemed to work so far, and in that sense, the use of Akka for
example is still a proposal only.

For major refactorings like the RPC/Actor one, it makes sense to try and
reach consensus before the implementation effort, because it is too much
work to do it without knowing that it will be accepted. This may be a vote,
but I would prefer it to be rather lightweight, like dropping a mail on the
dev list, giving people an early chance to voice concerns.

Does it make sense to write these simple rules down somewhere (wiki?), so
that it is transparent?

Stephan
Reply | Threaded
Open this post in threaded view
|

Re: Community & Committing rules

Márton Balassi
I'd prefer the mail vote before major changes (this is also the preferred
Apache guideline if I'm not mistaken).

Writing down the basics on a wiki makes it clearer and also easier for new
contributors to get involved. This page is somewhat related though (at
least for voting):
http://www.apache.org/foundation/voting.html


On Fri, Sep 5, 2014 at 12:50 PM, Stephan Ewen <[hidden email]> wrote:

> Hi!
>
> I think part of the discussion that arose around the proposed Java/Scala
> and RPC/Akka changes comes from the fact that we have not clearly written
> down the community/committing rules anywhere yet. In particular, how do we
> treat proposed major changes.
>
> Most of us (including me) worked under the assumption that committers can
> commit small fixes immediately, and those can be vetoed (reverted) in
> hind-sight by others (has not yet happened, though).
>
> Anything that has impact on other people goes through pull requests, and is
> then discussed upon, revised, or rejected. This seems to be the model that
> many other Apache projects use (like Mahout for example, Sebastian, correct
> my if I am wrong there).
>
> That has seemed to work so far, and in that sense, the use of Akka for
> example is still a proposal only.
>
> For major refactorings like the RPC/Actor one, it makes sense to try and
> reach consensus before the implementation effort, because it is too much
> work to do it without knowing that it will be accepted. This may be a vote,
> but I would prefer it to be rather lightweight, like dropping a mail on the
> dev list, giving people an early chance to voice concerns.
>
> Does it make sense to write these simple rules down somewhere (wiki?), so
> that it is transparent?
>
> Stephan
>
Reply | Threaded
Open this post in threaded view
|

Re: Community & Committing rules

Ufuk Celebi-2
+1 but I would say not the Wiki, but the How To Contribute guide.

@Marton: do you have a link for the mail vote befor major changes. In any
case, for me it doesn't matter whether it is a vote or a light weight mail
to the dev list.


On Fri, Sep 5, 2014 at 1:10 PM, Márton Balassi <[hidden email]>
wrote:

> I'd prefer the mail vote before major changes (this is also the preferred
> Apache guideline if I'm not mistaken).
>
> Writing down the basics on a wiki makes it clearer and also easier for new
> contributors to get involved. This page is somewhat related though (at
> least for voting):
> http://www.apache.org/foundation/voting.html
>
>
> On Fri, Sep 5, 2014 at 12:50 PM, Stephan Ewen <[hidden email]> wrote:
>
> > Hi!
> >
> > I think part of the discussion that arose around the proposed Java/Scala
> > and RPC/Akka changes comes from the fact that we have not clearly written
> > down the community/committing rules anywhere yet. In particular, how do
> we
> > treat proposed major changes.
> >
> > Most of us (including me) worked under the assumption that committers can
> > commit small fixes immediately, and those can be vetoed (reverted) in
> > hind-sight by others (has not yet happened, though).
> >
> > Anything that has impact on other people goes through pull requests, and
> is
> > then discussed upon, revised, or rejected. This seems to be the model
> that
> > many other Apache projects use (like Mahout for example, Sebastian,
> correct
> > my if I am wrong there).
> >
> > That has seemed to work so far, and in that sense, the use of Akka for
> > example is still a proposal only.
> >
> > For major refactorings like the RPC/Actor one, it makes sense to try and
> > reach consensus before the implementation effort, because it is too much
> > work to do it without knowing that it will be accepted. This may be a
> vote,
> > but I would prefer it to be rather lightweight, like dropping a mail on
> the
> > dev list, giving people an early chance to voice concerns.
> >
> > Does it make sense to write these simple rules down somewhere (wiki?), so
> > that it is transparent?
> >
> > Stephan
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Community & Committing rules

till.rohrmann
+1 for the community & committing rules.


On Fri, Sep 5, 2014 at 1:39 PM, Ufuk Celebi <[hidden email]> wrote:

> +1 but I would say not the Wiki, but the How To Contribute guide.
>
> @Marton: do you have a link for the mail vote befor major changes. In any
> case, for me it doesn't matter whether it is a vote or a light weight mail
> to the dev list.
>
>
> On Fri, Sep 5, 2014 at 1:10 PM, Márton Balassi <[hidden email]>
> wrote:
>
> > I'd prefer the mail vote before major changes (this is also the preferred
> > Apache guideline if I'm not mistaken).
> >
> > Writing down the basics on a wiki makes it clearer and also easier for
> new
> > contributors to get involved. This page is somewhat related though (at
> > least for voting):
> > http://www.apache.org/foundation/voting.html
> >
> >
> > On Fri, Sep 5, 2014 at 12:50 PM, Stephan Ewen <[hidden email]> wrote:
> >
> > > Hi!
> > >
> > > I think part of the discussion that arose around the proposed
> Java/Scala
> > > and RPC/Akka changes comes from the fact that we have not clearly
> written
> > > down the community/committing rules anywhere yet. In particular, how do
> > we
> > > treat proposed major changes.
> > >
> > > Most of us (including me) worked under the assumption that committers
> can
> > > commit small fixes immediately, and those can be vetoed (reverted) in
> > > hind-sight by others (has not yet happened, though).
> > >
> > > Anything that has impact on other people goes through pull requests,
> and
> > is
> > > then discussed upon, revised, or rejected. This seems to be the model
> > that
> > > many other Apache projects use (like Mahout for example, Sebastian,
> > correct
> > > my if I am wrong there).
> > >
> > > That has seemed to work so far, and in that sense, the use of Akka for
> > > example is still a proposal only.
> > >
> > > For major refactorings like the RPC/Actor one, it makes sense to try
> and
> > > reach consensus before the implementation effort, because it is too
> much
> > > work to do it without knowing that it will be accepted. This may be a
> > vote,
> > > but I would prefer it to be rather lightweight, like dropping a mail on
> > the
> > > dev list, giving people an early chance to voice concerns.
> > >
> > > Does it make sense to write these simple rules down somewhere (wiki?),
> so
> > > that it is transparent?
> > >
> > > Stephan
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Community & Committing rules

Robert Metzger
In reply to this post by Ufuk Celebi-2
I agree with Stephan: If somebody wants to do a major change and is
uncertain if the community is willing to accept the change, they can ask on
the mailing list about it.

I would rather go with Stephan's suggestion to just drop a mail on the dev@
list, without a formal vote. If there is a disagreement or somebody asks
for a vote, we can still start a vote. This is how I perceived this project
since it entered the incubator.

I'm against the explicit requirement for a vote (this is how I understood
Marton) because it would make things too complicated (working on Flink
should be fun, not a highly regulated process).


I'm against adding the community rules into the "How to Contrib". Its such
an important topic that we should dedicate a separate page on that (the
internet is already so huge, this one page won't hurt). Having such a page
also shows the IPMC that our community is healthy.



On Fri, Sep 5, 2014 at 1:39 PM, Ufuk Celebi <[hidden email]> wrote:

> +1 but I would say not the Wiki, but the How To Contribute guide.
>
> @Marton: do you have a link for the mail vote befor major changes. In any
> case, for me it doesn't matter whether it is a vote or a light weight mail
> to the dev list.
>
>
> On Fri, Sep 5, 2014 at 1:10 PM, Márton Balassi <[hidden email]>
> wrote:
>
> > I'd prefer the mail vote before major changes (this is also the preferred
> > Apache guideline if I'm not mistaken).
> >
> > Writing down the basics on a wiki makes it clearer and also easier for
> new
> > contributors to get involved. This page is somewhat related though (at
> > least for voting):
> > http://www.apache.org/foundation/voting.html
> >
> >
> > On Fri, Sep 5, 2014 at 12:50 PM, Stephan Ewen <[hidden email]> wrote:
> >
> > > Hi!
> > >
> > > I think part of the discussion that arose around the proposed
> Java/Scala
> > > and RPC/Akka changes comes from the fact that we have not clearly
> written
> > > down the community/committing rules anywhere yet. In particular, how do
> > we
> > > treat proposed major changes.
> > >
> > > Most of us (including me) worked under the assumption that committers
> can
> > > commit small fixes immediately, and those can be vetoed (reverted) in
> > > hind-sight by others (has not yet happened, though).
> > >
> > > Anything that has impact on other people goes through pull requests,
> and
> > is
> > > then discussed upon, revised, or rejected. This seems to be the model
> > that
> > > many other Apache projects use (like Mahout for example, Sebastian,
> > correct
> > > my if I am wrong there).
> > >
> > > That has seemed to work so far, and in that sense, the use of Akka for
> > > example is still a proposal only.
> > >
> > > For major refactorings like the RPC/Actor one, it makes sense to try
> and
> > > reach consensus before the implementation effort, because it is too
> much
> > > work to do it without knowing that it will be accepted. This may be a
> > vote,
> > > but I would prefer it to be rather lightweight, like dropping a mail on
> > the
> > > dev list, giving people an early chance to voice concerns.
> > >
> > > Does it make sense to write these simple rules down somewhere (wiki?),
> so
> > > that it is transparent?
> > >
> > > Stephan
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Community & Committing rules

Kostas Tzoumas-2
+1 for not requiring a vote thread unless someone asks for it


On Fri, Sep 5, 2014 at 1:51 PM, Robert Metzger <[hidden email]> wrote:

> I agree with Stephan: If somebody wants to do a major change and is
> uncertain if the community is willing to accept the change, they can ask on
> the mailing list about it.
>
> I would rather go with Stephan's suggestion to just drop a mail on the dev@
> list, without a formal vote. If there is a disagreement or somebody asks
> for a vote, we can still start a vote. This is how I perceived this project
> since it entered the incubator.
>
> I'm against the explicit requirement for a vote (this is how I understood
> Marton) because it would make things too complicated (working on Flink
> should be fun, not a highly regulated process).
>
>
> I'm against adding the community rules into the "How to Contrib". Its such
> an important topic that we should dedicate a separate page on that (the
> internet is already so huge, this one page won't hurt). Having such a page
> also shows the IPMC that our community is healthy.
>
>
>
> On Fri, Sep 5, 2014 at 1:39 PM, Ufuk Celebi <[hidden email]> wrote:
>
> > +1 but I would say not the Wiki, but the How To Contribute guide.
> >
> > @Marton: do you have a link for the mail vote befor major changes. In any
> > case, for me it doesn't matter whether it is a vote or a light weight
> mail
> > to the dev list.
> >
> >
> > On Fri, Sep 5, 2014 at 1:10 PM, Márton Balassi <[hidden email]
> >
> > wrote:
> >
> > > I'd prefer the mail vote before major changes (this is also the
> preferred
> > > Apache guideline if I'm not mistaken).
> > >
> > > Writing down the basics on a wiki makes it clearer and also easier for
> > new
> > > contributors to get involved. This page is somewhat related though (at
> > > least for voting):
> > > http://www.apache.org/foundation/voting.html
> > >
> > >
> > > On Fri, Sep 5, 2014 at 12:50 PM, Stephan Ewen <[hidden email]>
> wrote:
> > >
> > > > Hi!
> > > >
> > > > I think part of the discussion that arose around the proposed
> > Java/Scala
> > > > and RPC/Akka changes comes from the fact that we have not clearly
> > written
> > > > down the community/committing rules anywhere yet. In particular, how
> do
> > > we
> > > > treat proposed major changes.
> > > >
> > > > Most of us (including me) worked under the assumption that committers
> > can
> > > > commit small fixes immediately, and those can be vetoed (reverted) in
> > > > hind-sight by others (has not yet happened, though).
> > > >
> > > > Anything that has impact on other people goes through pull requests,
> > and
> > > is
> > > > then discussed upon, revised, or rejected. This seems to be the model
> > > that
> > > > many other Apache projects use (like Mahout for example, Sebastian,
> > > correct
> > > > my if I am wrong there).
> > > >
> > > > That has seemed to work so far, and in that sense, the use of Akka
> for
> > > > example is still a proposal only.
> > > >
> > > > For major refactorings like the RPC/Actor one, it makes sense to try
> > and
> > > > reach consensus before the implementation effort, because it is too
> > much
> > > > work to do it without knowing that it will be accepted. This may be a
> > > vote,
> > > > but I would prefer it to be rather lightweight, like dropping a mail
> on
> > > the
> > > > dev list, giving people an early chance to voice concerns.
> > > >
> > > > Does it make sense to write these simple rules down somewhere
> (wiki?),
> > so
> > > > that it is transparent?
> > > >
> > > > Stephan
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Community & Committing rules

Márton Balassi
The argument of Robert & Kostas on not requiring a vote thread unless
someone asks for it makes sense, mine was too much.


On Fri, Sep 5, 2014 at 2:33 PM, Kostas Tzoumas <[hidden email]> wrote:

> +1 for not requiring a vote thread unless someone asks for it
>
>
> On Fri, Sep 5, 2014 at 1:51 PM, Robert Metzger <[hidden email]>
> wrote:
>
> > I agree with Stephan: If somebody wants to do a major change and is
> > uncertain if the community is willing to accept the change, they can ask
> on
> > the mailing list about it.
> >
> > I would rather go with Stephan's suggestion to just drop a mail on the
> dev@
> > list, without a formal vote. If there is a disagreement or somebody asks
> > for a vote, we can still start a vote. This is how I perceived this
> project
> > since it entered the incubator.
> >
> > I'm against the explicit requirement for a vote (this is how I understood
> > Marton) because it would make things too complicated (working on Flink
> > should be fun, not a highly regulated process).
> >
> >
> > I'm against adding the community rules into the "How to Contrib". Its
> such
> > an important topic that we should dedicate a separate page on that (the
> > internet is already so huge, this one page won't hurt). Having such a
> page
> > also shows the IPMC that our community is healthy.
> >
> >
> >
> > On Fri, Sep 5, 2014 at 1:39 PM, Ufuk Celebi <[hidden email]> wrote:
> >
> > > +1 but I would say not the Wiki, but the How To Contribute guide.
> > >
> > > @Marton: do you have a link for the mail vote befor major changes. In
> any
> > > case, for me it doesn't matter whether it is a vote or a light weight
> > mail
> > > to the dev list.
> > >
> > >
> > > On Fri, Sep 5, 2014 at 1:10 PM, Márton Balassi <
> [hidden email]
> > >
> > > wrote:
> > >
> > > > I'd prefer the mail vote before major changes (this is also the
> > preferred
> > > > Apache guideline if I'm not mistaken).
> > > >
> > > > Writing down the basics on a wiki makes it clearer and also easier
> for
> > > new
> > > > contributors to get involved. This page is somewhat related though
> (at
> > > > least for voting):
> > > > http://www.apache.org/foundation/voting.html
> > > >
> > > >
> > > > On Fri, Sep 5, 2014 at 12:50 PM, Stephan Ewen <[hidden email]>
> > wrote:
> > > >
> > > > > Hi!
> > > > >
> > > > > I think part of the discussion that arose around the proposed
> > > Java/Scala
> > > > > and RPC/Akka changes comes from the fact that we have not clearly
> > > written
> > > > > down the community/committing rules anywhere yet. In particular,
> how
> > do
> > > > we
> > > > > treat proposed major changes.
> > > > >
> > > > > Most of us (including me) worked under the assumption that
> committers
> > > can
> > > > > commit small fixes immediately, and those can be vetoed (reverted)
> in
> > > > > hind-sight by others (has not yet happened, though).
> > > > >
> > > > > Anything that has impact on other people goes through pull
> requests,
> > > and
> > > > is
> > > > > then discussed upon, revised, or rejected. This seems to be the
> model
> > > > that
> > > > > many other Apache projects use (like Mahout for example, Sebastian,
> > > > correct
> > > > > my if I am wrong there).
> > > > >
> > > > > That has seemed to work so far, and in that sense, the use of Akka
> > for
> > > > > example is still a proposal only.
> > > > >
> > > > > For major refactorings like the RPC/Actor one, it makes sense to
> try
> > > and
> > > > > reach consensus before the implementation effort, because it is too
> > > much
> > > > > work to do it without knowing that it will be accepted. This may
> be a
> > > > vote,
> > > > > but I would prefer it to be rather lightweight, like dropping a
> mail
> > on
> > > > the
> > > > > dev list, giving people an early chance to voice concerns.
> > > > >
> > > > > Does it make sense to write these simple rules down somewhere
> > (wiki?),
> > > so
> > > > > that it is transparent?
> > > > >
> > > > > Stephan
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Community & Committing rules

Ufuk Celebi-2
In reply to this post by Kostas Tzoumas-2
I'm fine with an extra page. My initial reasoning for not going for the
Wiki was to make it more promiment on the homepage.

So no matter where we put it, let's make sure to have it as a sublink of
the "Community" navigation point.


On Fri, Sep 5, 2014 at 2:33 PM, Kostas Tzoumas <[hidden email]> wrote:

> +1 for not requiring a vote thread unless someone asks for it
>
>
> On Fri, Sep 5, 2014 at 1:51 PM, Robert Metzger <[hidden email]>
> wrote:
>
> > I agree with Stephan: If somebody wants to do a major change and is
> > uncertain if the community is willing to accept the change, they can ask
> on
> > the mailing list about it.
> >
> > I would rather go with Stephan's suggestion to just drop a mail on the
> dev@
> > list, without a formal vote. If there is a disagreement or somebody asks
> > for a vote, we can still start a vote. This is how I perceived this
> project
> > since it entered the incubator.
> >
> > I'm against the explicit requirement for a vote (this is how I understood
> > Marton) because it would make things too complicated (working on Flink
> > should be fun, not a highly regulated process).
> >
> >
> > I'm against adding the community rules into the "How to Contrib". Its
> such
> > an important topic that we should dedicate a separate page on that (the
> > internet is already so huge, this one page won't hurt). Having such a
> page
> > also shows the IPMC that our community is healthy.
> >
> >
> >
> > On Fri, Sep 5, 2014 at 1:39 PM, Ufuk Celebi <[hidden email]> wrote:
> >
> > > +1 but I would say not the Wiki, but the How To Contribute guide.
> > >
> > > @Marton: do you have a link for the mail vote befor major changes. In
> any
> > > case, for me it doesn't matter whether it is a vote or a light weight
> > mail
> > > to the dev list.
> > >
> > >
> > > On Fri, Sep 5, 2014 at 1:10 PM, Márton Balassi <
> [hidden email]
> > >
> > > wrote:
> > >
> > > > I'd prefer the mail vote before major changes (this is also the
> > preferred
> > > > Apache guideline if I'm not mistaken).
> > > >
> > > > Writing down the basics on a wiki makes it clearer and also easier
> for
> > > new
> > > > contributors to get involved. This page is somewhat related though
> (at
> > > > least for voting):
> > > > http://www.apache.org/foundation/voting.html
> > > >
> > > >
> > > > On Fri, Sep 5, 2014 at 12:50 PM, Stephan Ewen <[hidden email]>
> > wrote:
> > > >
> > > > > Hi!
> > > > >
> > > > > I think part of the discussion that arose around the proposed
> > > Java/Scala
> > > > > and RPC/Akka changes comes from the fact that we have not clearly
> > > written
> > > > > down the community/committing rules anywhere yet. In particular,
> how
> > do
> > > > we
> > > > > treat proposed major changes.
> > > > >
> > > > > Most of us (including me) worked under the assumption that
> committers
> > > can
> > > > > commit small fixes immediately, and those can be vetoed (reverted)
> in
> > > > > hind-sight by others (has not yet happened, though).
> > > > >
> > > > > Anything that has impact on other people goes through pull
> requests,
> > > and
> > > > is
> > > > > then discussed upon, revised, or rejected. This seems to be the
> model
> > > > that
> > > > > many other Apache projects use (like Mahout for example, Sebastian,
> > > > correct
> > > > > my if I am wrong there).
> > > > >
> > > > > That has seemed to work so far, and in that sense, the use of Akka
> > for
> > > > > example is still a proposal only.
> > > > >
> > > > > For major refactorings like the RPC/Actor one, it makes sense to
> try
> > > and
> > > > > reach consensus before the implementation effort, because it is too
> > > much
> > > > > work to do it without knowing that it will be accepted. This may
> be a
> > > > vote,
> > > > > but I would prefer it to be rather lightweight, like dropping a
> mail
> > on
> > > > the
> > > > > dev list, giving people an early chance to voice concerns.
> > > > >
> > > > > Does it make sense to write these simple rules down somewhere
> > (wiki?),
> > > so
> > > > > that it is transparent?
> > > > >
> > > > > Stephan
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Community & Committing rules

Henry Saputra
In reply to this post by Stephan Ewen
+1 for commits small changes directly, which is the perk of being
committers of open source project.

However, as many people had mentioned, when the changes are none
trivial or requires modification of existing behavior then a pull
request and reviews should be requested to get extra pairs of eyes.

And when it is a new feature or major changes, such as rewrite RPC
flows, then hopefully consensus of plan could achieve via discussions
in dev@ list and with opening JIRA ticket to track the effort.
VOTE should be done when consensus is hard to get and changes are
needed for greater good.

Having official commit rules are like having project bylaws.
I don't think we need bylaws of committing changes at this point,
because it would cause confusion and many existing Apache projects did
not get it right with formal bylaws.

- Henry

On Fri, Sep 5, 2014 at 3:50 AM, Stephan Ewen <[hidden email]> wrote:

> Hi!
>
> I think part of the discussion that arose around the proposed Java/Scala
> and RPC/Akka changes comes from the fact that we have not clearly written
> down the community/committing rules anywhere yet. In particular, how do we
> treat proposed major changes.
>
> Most of us (including me) worked under the assumption that committers can
> commit small fixes immediately, and those can be vetoed (reverted) in
> hind-sight by others (has not yet happened, though).
>
> Anything that has impact on other people goes through pull requests, and is
> then discussed upon, revised, or rejected. This seems to be the model that
> many other Apache projects use (like Mahout for example, Sebastian, correct
> my if I am wrong there).
>
> That has seemed to work so far, and in that sense, the use of Akka for
> example is still a proposal only.
>
> For major refactorings like the RPC/Actor one, it makes sense to try and
> reach consensus before the implementation effort, because it is too much
> work to do it without knowing that it will be accepted. This may be a vote,
> but I would prefer it to be rather lightweight, like dropping a mail on the
> dev list, giving people an early chance to voice concerns.
>
> Does it make sense to write these simple rules down somewhere (wiki?), so
> that it is transparent?
>
> Stephan
Reply | Threaded
Open this post in threaded view
|

Re: Community & Committing rules

Kostas Tzoumas-2
Henry, thank you *very much* for this input!

I agree, let us not put more structure/rules than needed at this point.


On Fri, Sep 5, 2014 at 6:58 PM, Henry Saputra <[hidden email]>
wrote:

> +1 for commits small changes directly, which is the perk of being
> committers of open source project.
>
> However, as many people had mentioned, when the changes are none
> trivial or requires modification of existing behavior then a pull
> request and reviews should be requested to get extra pairs of eyes.
>
> And when it is a new feature or major changes, such as rewrite RPC
> flows, then hopefully consensus of plan could achieve via discussions
> in dev@ list and with opening JIRA ticket to track the effort.
> VOTE should be done when consensus is hard to get and changes are
> needed for greater good.
>
> Having official commit rules are like having project bylaws.
> I don't think we need bylaws of committing changes at this point,
> because it would cause confusion and many existing Apache projects did
> not get it right with formal bylaws.
>
> - Henry
>
> On Fri, Sep 5, 2014 at 3:50 AM, Stephan Ewen <[hidden email]> wrote:
> > Hi!
> >
> > I think part of the discussion that arose around the proposed Java/Scala
> > and RPC/Akka changes comes from the fact that we have not clearly written
> > down the community/committing rules anywhere yet. In particular, how do
> we
> > treat proposed major changes.
> >
> > Most of us (including me) worked under the assumption that committers can
> > commit small fixes immediately, and those can be vetoed (reverted) in
> > hind-sight by others (has not yet happened, though).
> >
> > Anything that has impact on other people goes through pull requests, and
> is
> > then discussed upon, revised, or rejected. This seems to be the model
> that
> > many other Apache projects use (like Mahout for example, Sebastian,
> correct
> > my if I am wrong there).
> >
> > That has seemed to work so far, and in that sense, the use of Akka for
> > example is still a proposal only.
> >
> > For major refactorings like the RPC/Actor one, it makes sense to try and
> > reach consensus before the implementation effort, because it is too much
> > work to do it without knowing that it will be accepted. This may be a
> vote,
> > but I would prefer it to be rather lightweight, like dropping a mail on
> the
> > dev list, giving people an early chance to voice concerns.
> >
> > Does it make sense to write these simple rules down somewhere (wiki?), so
> > that it is transparent?
> >
> > Stephan
>