Re: [DISCUSS] Proposed Bylaws changes
Since there isn't clear consensus on part of this, I'm going to start 2 VOTE threads for changing the bylaws, one for the RFC process which has broad-spectrum support, and one for the +1 rule change. -Joan - Original Message - > From: "Reddy B." > To: priv...@couchdb.apache.org, dev@couchdb.apache.org, > woh...@apache.org > Sent: Sunday, February 17, 2019 1:51:20 PM > Subject: RE: [DISCUSS] Proposed Bylaws changes > As a user I would tend to find this safeguard reassuring. > For example, when developments such as the FDB branch are happening, > this would provide the community additional peace of mind. > I too think that the problem addressed by this proposal doesn't exist > (yet? ) in this project. I am very impressed and admirative of the > quality of this community. But considering what's happening in the > wild and the manoeuvering of certain companies, it's difficult not > to feel naive by always assuming good faith. > I also do not think that this bylaw would assume bad faith, the way I > see it, it would put everyone in a better position to assume good > faith. This is similar to discussing with your spouse giving each > other a GPS tracker (an app or something) so that one spouse can now > where the other is at all times. Is it about building trust, or is > it about distrust. This is the situation we are in. > I think that once the issue is brought up by one the spouses, it > becomes something you need to deal with as early as possible to save > the marriage, otherwise worries will turn into distrust, which will > turn into perceptions and from that point, hell is the only limit > left. My view is that a solution in the form of a rule applying to > both spouses equally is a good compromise that is building trust > rather than assuming distrust. > Forgive the analogy. > De : Joan Touzet > Envoyé : vendredi 15 février 2019 20:00:14 > À : priv...@couchdb.apache.org > Cc : dev@couchdb.apache.org > Objet : Re: [DISCUSS] Proposed Bylaws changes > And yet we have evidence from other ASF projects that this is not > always the case. > All I am trying to do is have a backstop against that from happening > here. > But if no one wants it, then fine, I give up. > -Joan > - Original Message - > > From: "Robert Newson" > > To: dev@couchdb.apache.org > > Cc: "priv...@couchdb.apache.org Private" > > > > Sent: Friday, February 15, 2019 1:57:14 PM > > Subject: Re: [DISCUSS] Proposed Bylaws changes > > > > https://apache.org/foundation/how-it-works.html#hats > > > > INDIVIDUALS COMPOSE THE ASF > > All of the ASF including the board, the other officers, the > > committers, and the members, are participating as individuals. That > > is one strength of the ASF, affiliations do not cloud the personal > > contributions. > > > > Unless they specifically state otherwise, whatever they post on any > > mailing list is done as themselves. It is the individual > > point-of-view, wearing their personal hat and not as a mouthpiece > > for whatever company happens to be signing their paychecks right > > now, and not even as a director of the ASF. > > > > All of those ASF people implicitly have multiple hats, especially > > the > > Board, the other officers, and the PMC chairs. They sometimes need > > to talk about a matter of policy, so to avoid appearing to be > > expressing a personal opinion, they will state that they are > > talking > > in their special capacity. However, most of the time this is not > > necessary, personal opinions work well. > > > > Some people declare their hats by using a special footer to their > > email, others enclose their statements in special quotation marks, > > others use their apache.org email address when otherwise they would > > use their personal one. This latter method is not reliable, as many > > people use their apache.org address all of the time. > > > > -- > > Robert Samuel Newson > > rnew...@apache.org > > > > On Fri, 15 Feb 2019, at 18:47, Joan Touzet wrote: > > > Garren, > > > > > > RFCs are intended for major changes to our projects, not for > > > minor > > > improvments. > > > > > > Do you foresee massive changes to nano and fauxton? > > > > > > Do you not see that a single employer driving ~all the > > > development > > > of either or both of these as a significant concern re: the > > > health > > > of our community? > > > > > > -Joan > > > > > > - Original Message - > > > > From:
RE: [DISCUSS] Proposed Bylaws changes
As a user I would tend to find this safeguard reassuring. For example, when developments such as the FDB branch are happening, this would provide the community additional peace of mind. I too think that the problem addressed by this proposal doesn't exist (yet? ) in this project. I am very impressed and admirative of the quality of this community. But considering what's happening in the wild and the manoeuvering of certain companies, it's difficult not to feel naive by always assuming good faith. I also do not think that this bylaw would assume bad faith, the way I see it, it would put everyone in a better position to assume good faith. This is similar to discussing with your spouse giving each other a GPS tracker (an app or something) so that one spouse can now where the other is at all times. Is it about building trust, or is it about distrust. This is the situation we are in. I think that once the issue is brought up by one the spouses, it becomes something you need to deal with as early as possible to save the marriage, otherwise worries will turn into distrust, which will turn into perceptions and from that point, hell is the only limit left. My view is that a solution in the form of a rule applying to both spouses equally is a good compromise that is building trust rather than assuming distrust. Forgive the analogy. De : Joan Touzet Envoyé : vendredi 15 février 2019 20:00:14 À : priv...@couchdb.apache.org Cc : dev@couchdb.apache.org Objet : Re: [DISCUSS] Proposed Bylaws changes And yet we have evidence from other ASF projects that this is not always the case. All I am trying to do is have a backstop against that from happening here. But if no one wants it, then fine, I give up. -Joan - Original Message - > From: "Robert Newson" > To: dev@couchdb.apache.org > Cc: "priv...@couchdb.apache.org Private" > Sent: Friday, February 15, 2019 1:57:14 PM > Subject: Re: [DISCUSS] Proposed Bylaws changes > > https://apache.org/foundation/how-it-works.html#hats > > INDIVIDUALS COMPOSE THE ASF > All of the ASF including the board, the other officers, the > committers, and the members, are participating as individuals. That > is one strength of the ASF, affiliations do not cloud the personal > contributions. > > Unless they specifically state otherwise, whatever they post on any > mailing list is done as themselves. It is the individual > point-of-view, wearing their personal hat and not as a mouthpiece > for whatever company happens to be signing their paychecks right > now, and not even as a director of the ASF. > > All of those ASF people implicitly have multiple hats, especially the > Board, the other officers, and the PMC chairs. They sometimes need > to talk about a matter of policy, so to avoid appearing to be > expressing a personal opinion, they will state that they are talking > in their special capacity. However, most of the time this is not > necessary, personal opinions work well. > > Some people declare their hats by using a special footer to their > email, others enclose their statements in special quotation marks, > others use their apache.org email address when otherwise they would > use their personal one. This latter method is not reliable, as many > people use their apache.org address all of the time. > > -- > Robert Samuel Newson > rnew...@apache.org > > On Fri, 15 Feb 2019, at 18:47, Joan Touzet wrote: > > Garren, > > > > RFCs are intended for major changes to our projects, not for minor > > improvments. > > > > Do you foresee massive changes to nano and fauxton? > > > > Do you not see that a single employer driving ~all the development > > of either or both of these as a significant concern re: the health > > of our community? > > > > -Joan > > > > - Original Message - > > > From: "Garren Smith" > > > To: "priv...@couchdb.apache.org Private" > > > , "Joan Touzet" > > > Cc: "CouchDB Developers" > > > Sent: Friday, February 15, 2019 2:56:04 AM > > > Subject: Re: [DISCUSS] Proposed Bylaws changes > > > > > > I'm also not super keen on the "not directly affiliated with the > > > proposer's > > > employer”. I think this will put unnecessary strain on the > > > community. > > > Take > > > the Fauxton and Nano.js project. The majority of work on those > > > projects > > > come from IBM affiliated developers. We do have a smaller group > > > of > > > community developers. That small group of community developers > > > would > > > have > > > to review all RFC's and approve them and
Re: [DISCUSS] Proposed Bylaws changes
https://apache.org/foundation/how-it-works.html#hats INDIVIDUALS COMPOSE THE ASF All of the ASF including the board, the other officers, the committers, and the members, are participating as individuals. That is one strength of the ASF, affiliations do not cloud the personal contributions. Unless they specifically state otherwise, whatever they post on any mailing list is done as themselves. It is the individual point-of-view, wearing their personal hat and not as a mouthpiece for whatever company happens to be signing their paychecks right now, and not even as a director of the ASF. All of those ASF people implicitly have multiple hats, especially the Board, the other officers, and the PMC chairs. They sometimes need to talk about a matter of policy, so to avoid appearing to be expressing a personal opinion, they will state that they are talking in their special capacity. However, most of the time this is not necessary, personal opinions work well. Some people declare their hats by using a special footer to their email, others enclose their statements in special quotation marks, others use their apache.org email address when otherwise they would use their personal one. This latter method is not reliable, as many people use their apache.org address all of the time. -- Robert Samuel Newson rnew...@apache.org On Fri, 15 Feb 2019, at 18:47, Joan Touzet wrote: > Garren, > > RFCs are intended for major changes to our projects, not for minor > improvments. > > Do you foresee massive changes to nano and fauxton? > > Do you not see that a single employer driving ~all the development > of either or both of these as a significant concern re: the health > of our community? > > -Joan > > - Original Message - > > From: "Garren Smith" > > To: "priv...@couchdb.apache.org Private" , > > "Joan Touzet" > > Cc: "CouchDB Developers" > > Sent: Friday, February 15, 2019 2:56:04 AM > > Subject: Re: [DISCUSS] Proposed Bylaws changes > > > > I'm also not super keen on the "not directly affiliated with the > > proposer's > > employer”. I think this will put unnecessary strain on the community. > > Take > > the Fauxton and Nano.js project. The majority of work on those > > projects > > come from IBM affiliated developers. We do have a smaller group of > > community developers. That small group of community developers would > > have > > to review all RFC's and approve them and ideally not hold up > > development on > > a feature for a few weeks while they try and find time to get to it. > > > > On Fri, Feb 15, 2019 at 12:49 AM Joan Touzet > > wrote: > > > > > Hi, > > > > > > Thanks. I'll make another attempt to sway others, and I'd like to > > > hear > > > from more people on this thread. > > > > > > I don't see the harm in this, it would rarely if ever be invoked, > > > and > > > it allows us to point to a concrete, solid action we have taken to > > > ensure we don't have a runaway project in the future. I would think > > > it could be a guiding light for other ASF projects that have lost > > > their > > > way (where we, I continue to assert, have not). > > > > > > Remember that votes on RFCs are the *committer* community, not the > > > PMC. > > > I'd be shocked if the PMC remained entirely silent on a proposal, > > > but > > > it indeed could be possible that committers could get an RFC > > > together > > > "while the PMC isn't looking" (say, over a holiday). Granted it'd > > > be in > > > bad form, and the PMC could still take steps to correct things > > > after > > > the action, but it'd be annoying to deal with. > > > > > > Again all I am trying to do here is put in a limiter in case the > > > PMC > > > and committer base /were/ to get stacked against the community. If > > > that > > > were to occur, your argument that the PMC could step in at that > > > point > > > is moot, because the PMC would already be stacked in that > > > direction. > > > This would protect the community from the negative effects of that > > > happening. > > > > > > -Joan > > > > > > > > > > > > - Original Message - > > > > From: "Robert Samuel Newson" > > > > To: "Joan Touzet" > > > > Cc: "CouchDB Developers" , "CouchDB PMC" > > > > < > > > priv...@couchdb.apache.org> > > > > Sent:
Re: [DISCUSS] Proposed Bylaws changes
And yet we have evidence from other ASF projects that this is not always the case. All I am trying to do is have a backstop against that from happening here. But if no one wants it, then fine, I give up. -Joan - Original Message - > From: "Robert Newson" > To: dev@couchdb.apache.org > Cc: "priv...@couchdb.apache.org Private" > Sent: Friday, February 15, 2019 1:57:14 PM > Subject: Re: [DISCUSS] Proposed Bylaws changes > > https://apache.org/foundation/how-it-works.html#hats > > INDIVIDUALS COMPOSE THE ASF > All of the ASF including the board, the other officers, the > committers, and the members, are participating as individuals. That > is one strength of the ASF, affiliations do not cloud the personal > contributions. > > Unless they specifically state otherwise, whatever they post on any > mailing list is done as themselves. It is the individual > point-of-view, wearing their personal hat and not as a mouthpiece > for whatever company happens to be signing their paychecks right > now, and not even as a director of the ASF. > > All of those ASF people implicitly have multiple hats, especially the > Board, the other officers, and the PMC chairs. They sometimes need > to talk about a matter of policy, so to avoid appearing to be > expressing a personal opinion, they will state that they are talking > in their special capacity. However, most of the time this is not > necessary, personal opinions work well. > > Some people declare their hats by using a special footer to their > email, others enclose their statements in special quotation marks, > others use their apache.org email address when otherwise they would > use their personal one. This latter method is not reliable, as many > people use their apache.org address all of the time. > > -- > Robert Samuel Newson > rnew...@apache.org > > On Fri, 15 Feb 2019, at 18:47, Joan Touzet wrote: > > Garren, > > > > RFCs are intended for major changes to our projects, not for minor > > improvments. > > > > Do you foresee massive changes to nano and fauxton? > > > > Do you not see that a single employer driving ~all the development > > of either or both of these as a significant concern re: the health > > of our community? > > > > -Joan > > > > - Original Message - > > > From: "Garren Smith" > > > To: "priv...@couchdb.apache.org Private" > > > , "Joan Touzet" > > > Cc: "CouchDB Developers" > > > Sent: Friday, February 15, 2019 2:56:04 AM > > > Subject: Re: [DISCUSS] Proposed Bylaws changes > > > > > > I'm also not super keen on the "not directly affiliated with the > > > proposer's > > > employer”. I think this will put unnecessary strain on the > > > community. > > > Take > > > the Fauxton and Nano.js project. The majority of work on those > > > projects > > > come from IBM affiliated developers. We do have a smaller group > > > of > > > community developers. That small group of community developers > > > would > > > have > > > to review all RFC's and approve them and ideally not hold up > > > development on > > > a feature for a few weeks while they try and find time to get to > > > it. > > > > > > On Fri, Feb 15, 2019 at 12:49 AM Joan Touzet > > > wrote: > > > > > > > Hi, > > > > > > > > Thanks. I'll make another attempt to sway others, and I'd like > > > > to > > > > hear > > > > from more people on this thread. > > > > > > > > I don't see the harm in this, it would rarely if ever be > > > > invoked, > > > > and > > > > it allows us to point to a concrete, solid action we have taken > > > > to > > > > ensure we don't have a runaway project in the future. I would > > > > think > > > > it could be a guiding light for other ASF projects that have > > > > lost > > > > their > > > > way (where we, I continue to assert, have not). > > > > > > > > Remember that votes on RFCs are the *committer* community, not > > > > the > > > > PMC. > > > > I'd be shocked if the PMC remained entirely silent on a > > > > proposal, > > > > but > > > > it indeed could be possible that committers could get an RFC > > > > together > > > > "while the PMC isn't looking" (say, over a holiday). Grant
Re: [DISCUSS] Proposed Bylaws changes
Garren, RFCs are intended for major changes to our projects, not for minor improvments. Do you foresee massive changes to nano and fauxton? Do you not see that a single employer driving ~all the development of either or both of these as a significant concern re: the health of our community? -Joan - Original Message - > From: "Garren Smith" > To: "priv...@couchdb.apache.org Private" , "Joan > Touzet" > Cc: "CouchDB Developers" > Sent: Friday, February 15, 2019 2:56:04 AM > Subject: Re: [DISCUSS] Proposed Bylaws changes > > I'm also not super keen on the "not directly affiliated with the > proposer's > employer”. I think this will put unnecessary strain on the community. > Take > the Fauxton and Nano.js project. The majority of work on those > projects > come from IBM affiliated developers. We do have a smaller group of > community developers. That small group of community developers would > have > to review all RFC's and approve them and ideally not hold up > development on > a feature for a few weeks while they try and find time to get to it. > > On Fri, Feb 15, 2019 at 12:49 AM Joan Touzet > wrote: > > > Hi, > > > > Thanks. I'll make another attempt to sway others, and I'd like to > > hear > > from more people on this thread. > > > > I don't see the harm in this, it would rarely if ever be invoked, > > and > > it allows us to point to a concrete, solid action we have taken to > > ensure we don't have a runaway project in the future. I would think > > it could be a guiding light for other ASF projects that have lost > > their > > way (where we, I continue to assert, have not). > > > > Remember that votes on RFCs are the *committer* community, not the > > PMC. > > I'd be shocked if the PMC remained entirely silent on a proposal, > > but > > it indeed could be possible that committers could get an RFC > > together > > "while the PMC isn't looking" (say, over a holiday). Granted it'd > > be in > > bad form, and the PMC could still take steps to correct things > > after > > the action, but it'd be annoying to deal with. > > > > Again all I am trying to do here is put in a limiter in case the > > PMC > > and committer base /were/ to get stacked against the community. If > > that > > were to occur, your argument that the PMC could step in at that > > point > > is moot, because the PMC would already be stacked in that > > direction. > > This would protect the community from the negative effects of that > > happening. > > > > -Joan > > > > > > > > - Original Message - > > > From: "Robert Samuel Newson" > > > To: "Joan Touzet" > > > Cc: "CouchDB Developers" , "CouchDB PMC" > > > < > > priv...@couchdb.apache.org> > > > Sent: Thursday, February 14, 2019 4:46:35 PM > > > Subject: Re: [DISCUSS] Proposed Bylaws changes > > > > > > Hi, > > > > > > Sure. > > > > > > Any member of the PMC who is railroading changes through on > > > behalf of > > > their employer to the detriment of this project should be > > > disciplined, ultimately losing their PMC membership (and their > > > binding vote on future changes). > > > > > > The "not directly affiliated with proposer's employer” seems to > > > presume bad faith on the part of some of those with binding votes > > > at > > > worst, and, at best, is stating that the PMC already distrusts > > > its > > > members that happen to be employed by IBM. If that is currently > > > the > > > case, the PMC should act directly and censure those members who > > > have > > > acted contrary to the requirements of an ASF PMC member. > > > > > > I don’t see how this piece is coupled with RFC, especially when > > > writing RFC’s, and taking them through a community review > > > process, > > > is likely to mitigate the issue of significant work being > > > designed > > > in private but ultimately contributed to CouchDB publicly. > > > > > > If the “RFC before code” approach does not work out, I will add > > > my > > > support to the affiliation requirement, but with a heavy heart. > > > To > > > presume such bad faith within the PMC, or to suspect it so > > > strongly > > > as to embed pre-emptive measures into our bylaws, points at > > > issues >
Re: [DISCUSS] Proposed Bylaws changes
A counter point would be* that this would be a forcing function for the folks who do the work here to use some of their time for community building so that that delay won’t ever happen. * I’m not saying I’m making this argument, but it might be a useful point to consider. * * * I also don’t think this proposal is based on a priori bad faith, but as a safety net for habits that are easy to fall into. Best Jan — > On 15. Feb 2019, at 08:56, Garren Smith wrote: > > I'm also not super keen on the "not directly affiliated with the proposer's > employer”. I think this will put unnecessary strain on the community. Take > the Fauxton and Nano.js project. The majority of work on those projects > come from IBM affiliated developers. We do have a smaller group of > community developers. That small group of community developers would have > to review all RFC's and approve them and ideally not hold up development on > a feature for a few weeks while they try and find time to get to it. > > On Fri, Feb 15, 2019 at 12:49 AM Joan Touzet wrote: > >> Hi, >> >> Thanks. I'll make another attempt to sway others, and I'd like to hear >> from more people on this thread. >> >> I don't see the harm in this, it would rarely if ever be invoked, and >> it allows us to point to a concrete, solid action we have taken to >> ensure we don't have a runaway project in the future. I would think >> it could be a guiding light for other ASF projects that have lost their >> way (where we, I continue to assert, have not). >> >> Remember that votes on RFCs are the *committer* community, not the PMC. >> I'd be shocked if the PMC remained entirely silent on a proposal, but >> it indeed could be possible that committers could get an RFC together >> "while the PMC isn't looking" (say, over a holiday). Granted it'd be in >> bad form, and the PMC could still take steps to correct things after >> the action, but it'd be annoying to deal with. >> >> Again all I am trying to do here is put in a limiter in case the PMC >> and committer base /were/ to get stacked against the community. If that >> were to occur, your argument that the PMC could step in at that point >> is moot, because the PMC would already be stacked in that direction. >> This would protect the community from the negative effects of that >> happening. >> >> -Joan >> >> >> >> - Original Message ----- >>> From: "Robert Samuel Newson" >>> To: "Joan Touzet" >>> Cc: "CouchDB Developers" , "CouchDB PMC" < >> priv...@couchdb.apache.org> >>> Sent: Thursday, February 14, 2019 4:46:35 PM >>> Subject: Re: [DISCUSS] Proposed Bylaws changes >>> >>> Hi, >>> >>> Sure. >>> >>> Any member of the PMC who is railroading changes through on behalf of >>> their employer to the detriment of this project should be >>> disciplined, ultimately losing their PMC membership (and their >>> binding vote on future changes). >>> >>> The "not directly affiliated with proposer's employer” seems to >>> presume bad faith on the part of some of those with binding votes at >>> worst, and, at best, is stating that the PMC already distrusts its >>> members that happen to be employed by IBM. If that is currently the >>> case, the PMC should act directly and censure those members who have >>> acted contrary to the requirements of an ASF PMC member. >>> >>> I don’t see how this piece is coupled with RFC, especially when >>> writing RFC’s, and taking them through a community review process, >>> is likely to mitigate the issue of significant work being designed >>> in private but ultimately contributed to CouchDB publicly. >>> >>> If the “RFC before code” approach does not work out, I will add my >>> support to the affiliation requirement, but with a heavy heart. To >>> presume such bad faith within the PMC, or to suspect it so strongly >>> as to embed pre-emptive measures into our bylaws, points at issues >>> deeper than a bylaw change can reasonably address. Other, stronger >>> responses would seem more appropriate should that come to pass. >>> >>> B. >>> >>>> On 14 Feb 2019, at 21:31, Joan Touzet wrote: >>>> >>>> Hi Robert, >>>> >>>> Care to give any more detail on your -1? >>>> >>>> I gave a fairly extensive argument as to why I think such a >>>> safeguard is important for our community. I a
Re: [DISCUSS] Proposed Bylaws changes
I'm also not super keen on the "not directly affiliated with the proposer's employer”. I think this will put unnecessary strain on the community. Take the Fauxton and Nano.js project. The majority of work on those projects come from IBM affiliated developers. We do have a smaller group of community developers. That small group of community developers would have to review all RFC's and approve them and ideally not hold up development on a feature for a few weeks while they try and find time to get to it. On Fri, Feb 15, 2019 at 12:49 AM Joan Touzet wrote: > Hi, > > Thanks. I'll make another attempt to sway others, and I'd like to hear > from more people on this thread. > > I don't see the harm in this, it would rarely if ever be invoked, and > it allows us to point to a concrete, solid action we have taken to > ensure we don't have a runaway project in the future. I would think > it could be a guiding light for other ASF projects that have lost their > way (where we, I continue to assert, have not). > > Remember that votes on RFCs are the *committer* community, not the PMC. > I'd be shocked if the PMC remained entirely silent on a proposal, but > it indeed could be possible that committers could get an RFC together > "while the PMC isn't looking" (say, over a holiday). Granted it'd be in > bad form, and the PMC could still take steps to correct things after > the action, but it'd be annoying to deal with. > > Again all I am trying to do here is put in a limiter in case the PMC > and committer base /were/ to get stacked against the community. If that > were to occur, your argument that the PMC could step in at that point > is moot, because the PMC would already be stacked in that direction. > This would protect the community from the negative effects of that > happening. > > -Joan > > > > - Original Message - > > From: "Robert Samuel Newson" > > To: "Joan Touzet" > > Cc: "CouchDB Developers" , "CouchDB PMC" < > priv...@couchdb.apache.org> > > Sent: Thursday, February 14, 2019 4:46:35 PM > > Subject: Re: [DISCUSS] Proposed Bylaws changes > > > > Hi, > > > > Sure. > > > > Any member of the PMC who is railroading changes through on behalf of > > their employer to the detriment of this project should be > > disciplined, ultimately losing their PMC membership (and their > > binding vote on future changes). > > > > The "not directly affiliated with proposer's employer” seems to > > presume bad faith on the part of some of those with binding votes at > > worst, and, at best, is stating that the PMC already distrusts its > > members that happen to be employed by IBM. If that is currently the > > case, the PMC should act directly and censure those members who have > > acted contrary to the requirements of an ASF PMC member. > > > > I don’t see how this piece is coupled with RFC, especially when > > writing RFC’s, and taking them through a community review process, > > is likely to mitigate the issue of significant work being designed > > in private but ultimately contributed to CouchDB publicly. > > > > If the “RFC before code” approach does not work out, I will add my > > support to the affiliation requirement, but with a heavy heart. To > > presume such bad faith within the PMC, or to suspect it so strongly > > as to embed pre-emptive measures into our bylaws, points at issues > > deeper than a bylaw change can reasonably address. Other, stronger > > responses would seem more appropriate should that come to pass. > > > > B. > > > > > On 14 Feb 2019, at 21:31, Joan Touzet wrote: > > > > > > Hi Robert, > > > > > > Care to give any more detail on your -1? > > > > > > I gave a fairly extensive argument as to why I think such a > > > safeguard is important for our community. I also feel it would > > > be meaningless to push through an RFC without community support. > > > But our current bylaws would make this very straightforward. > > > Why not put in this "backstop?" > > > > > > -Joan > > > > > > - Original Message - > > >> From: "Robert Samuel Newson" > > >> To: "CouchDB PMC" > > >> Cc: "Joan Touzet" , "CouchDB Developers" > > >> > > >> Sent: Thursday, February 14, 2019 4:26:31 PM > > >> Subject: Re: [DISCUSS] Proposed Bylaws changes > > >> > > >> I am +1 on the RFC’s and -1 on the "not directly affiliated with > > >>
Re: [DISCUSS] Proposed Bylaws changes
Hi, Thanks. I'll make another attempt to sway others, and I'd like to hear from more people on this thread. I don't see the harm in this, it would rarely if ever be invoked, and it allows us to point to a concrete, solid action we have taken to ensure we don't have a runaway project in the future. I would think it could be a guiding light for other ASF projects that have lost their way (where we, I continue to assert, have not). Remember that votes on RFCs are the *committer* community, not the PMC. I'd be shocked if the PMC remained entirely silent on a proposal, but it indeed could be possible that committers could get an RFC together "while the PMC isn't looking" (say, over a holiday). Granted it'd be in bad form, and the PMC could still take steps to correct things after the action, but it'd be annoying to deal with. Again all I am trying to do here is put in a limiter in case the PMC and committer base /were/ to get stacked against the community. If that were to occur, your argument that the PMC could step in at that point is moot, because the PMC would already be stacked in that direction. This would protect the community from the negative effects of that happening. -Joan - Original Message - > From: "Robert Samuel Newson" > To: "Joan Touzet" > Cc: "CouchDB Developers" , "CouchDB PMC" > > Sent: Thursday, February 14, 2019 4:46:35 PM > Subject: Re: [DISCUSS] Proposed Bylaws changes > > Hi, > > Sure. > > Any member of the PMC who is railroading changes through on behalf of > their employer to the detriment of this project should be > disciplined, ultimately losing their PMC membership (and their > binding vote on future changes). > > The "not directly affiliated with proposer's employer” seems to > presume bad faith on the part of some of those with binding votes at > worst, and, at best, is stating that the PMC already distrusts its > members that happen to be employed by IBM. If that is currently the > case, the PMC should act directly and censure those members who have > acted contrary to the requirements of an ASF PMC member. > > I don’t see how this piece is coupled with RFC, especially when > writing RFC’s, and taking them through a community review process, > is likely to mitigate the issue of significant work being designed > in private but ultimately contributed to CouchDB publicly. > > If the “RFC before code” approach does not work out, I will add my > support to the affiliation requirement, but with a heavy heart. To > presume such bad faith within the PMC, or to suspect it so strongly > as to embed pre-emptive measures into our bylaws, points at issues > deeper than a bylaw change can reasonably address. Other, stronger > responses would seem more appropriate should that come to pass. > > B. > > > On 14 Feb 2019, at 21:31, Joan Touzet wrote: > > > > Hi Robert, > > > > Care to give any more detail on your -1? > > > > I gave a fairly extensive argument as to why I think such a > > safeguard is important for our community. I also feel it would > > be meaningless to push through an RFC without community support. > > But our current bylaws would make this very straightforward. > > Why not put in this "backstop?" > > > > -Joan > > > > - Original Message - > >> From: "Robert Samuel Newson" > >> To: "CouchDB PMC" > >> Cc: "Joan Touzet" , "CouchDB Developers" > >> > >> Sent: Thursday, February 14, 2019 4:26:31 PM > >> Subject: Re: [DISCUSS] Proposed Bylaws changes > >> > >> I am +1 on the RFC’s and -1 on the "not directly affiliated with > >> the > >> proposer's employer” item. > >> > >> B. > >> > >>> On 13 Feb 2019, at 11:13, Jan Lehnardt wrote: > >>> > >>> Sounds fantastic, thanks too for the additional context! I’d love > >>> for us to lead the way here (yet again). > >>> > >>> Best > >>> Jan > >>> — > >>> > >>>> On 12. Feb 2019, at 20:15, Joan Touzet > >>>> wrote: > >>>> > >>>> Hi everyone, > >>>> > >>>> There appears to be general consensus on the RFC process, with > >>>> no > >>>> objections to the proposal itself. > >>>> > >>>> I'd like to propose the following changes to our bylaws: > >>>> > >>>> https://github.com/apache/couchdb-www/commit/8ae3a5a230b1717d7affe23625eeb288635aa542 > >>>> > >>>>
Re: [DISCUSS] Proposed Bylaws changes
Hi, Sure. Any member of the PMC who is railroading changes through on behalf of their employer to the detriment of this project should be disciplined, ultimately losing their PMC membership (and their binding vote on future changes). The "not directly affiliated with proposer's employer” seems to presume bad faith on the part of some of those with binding votes at worst, and, at best, is stating that the PMC already distrusts its members that happen to be employed by IBM. If that is currently the case, the PMC should act directly and censure those members who have acted contrary to the requirements of an ASF PMC member. I don’t see how this piece is coupled with RFC, especially when writing RFC’s, and taking them through a community review process, is likely to mitigate the issue of significant work being designed in private but ultimately contributed to CouchDB publicly. If the “RFC before code” approach does not work out, I will add my support to the affiliation requirement, but with a heavy heart. To presume such bad faith within the PMC, or to suspect it so strongly as to embed pre-emptive measures into our bylaws, points at issues deeper than a bylaw change can reasonably address. Other, stronger responses would seem more appropriate should that come to pass. B. > On 14 Feb 2019, at 21:31, Joan Touzet wrote: > > Hi Robert, > > Care to give any more detail on your -1? > > I gave a fairly extensive argument as to why I think such a > safeguard is important for our community. I also feel it would > be meaningless to push through an RFC without community support. > But our current bylaws would make this very straightforward. > Why not put in this "backstop?" > > -Joan > > - Original Message - >> From: "Robert Samuel Newson" >> To: "CouchDB PMC" >> Cc: "Joan Touzet" , "CouchDB Developers" >> >> Sent: Thursday, February 14, 2019 4:26:31 PM >> Subject: Re: [DISCUSS] Proposed Bylaws changes >> >> I am +1 on the RFC’s and -1 on the "not directly affiliated with the >> proposer's employer” item. >> >> B. >> >>> On 13 Feb 2019, at 11:13, Jan Lehnardt wrote: >>> >>> Sounds fantastic, thanks too for the additional context! I’d love >>> for us to lead the way here (yet again). >>> >>> Best >>> Jan >>> — >>> >>>> On 12. Feb 2019, at 20:15, Joan Touzet wrote: >>>> >>>> Hi everyone, >>>> >>>> There appears to be general consensus on the RFC process, with no >>>> objections to the proposal itself. >>>> >>>> I'd like to propose the following changes to our bylaws: >>>> >>>> https://github.com/apache/couchdb-www/commit/8ae3a5a230b1717d7affe23625eeb288635aa542 >>>> >>>> Quick summary: >>>> >>>> * Added the RFC proposal process >>>> * The RFC will become an official template as part of this >>>> * https://github.com/apache/couchdb/pull/1914 adds Bob's request >>>>to include a Security section >>>> >>>> * Proposed a new "qualified lazy majority" approval model for >>>> RFCs: >>>> * Requires 3 binding +1 votes >>>> * Requires more binding +1 votes than binding -1 votes >>>> * (NEW) Requires at least +1 binding vote from an individual >>>>not directly affiliated with the proposer's employer (if >>>>applicable) >>>> >>>> * Changed URLs to use the new Pony Mail web interface (yay!) >>>> >>>> While today we are in a great situation where no single entity >>>> dominates >>>> CouchDB development (to the exclusion of others), I believe this >>>> new >>>> approval model (just for RFCs) will prevent that from occurring in >>>> the >>>> future, and will ease a long-standing concern I have held. >>>> >>>> >>>> If there is no strong objection, I will start the VOTE later this >>>> week. >>>> As this is both creating and amending our official documents, the >>>> vote >>>> will be a lazy 2/3 majority vote, with binding votes only from PMC >>>> members. >>>> >>>> >>>> Why is this so important to me? Recently, on another ASF mailing >>>> list, >>>> there was a discussion about some of the changes happening in the >>>> commercial world, and as it relates to big companies giving back >>>> to op
Re: [DISCUSS] Proposed Bylaws changes
Hi Robert, Care to give any more detail on your -1? I gave a fairly extensive argument as to why I think such a safeguard is important for our community. I also feel it would be meaningless to push through an RFC without community support. But our current bylaws would make this very straightforward. Why not put in this "backstop?" -Joan - Original Message - > From: "Robert Samuel Newson" > To: "CouchDB PMC" > Cc: "Joan Touzet" , "CouchDB Developers" > > Sent: Thursday, February 14, 2019 4:26:31 PM > Subject: Re: [DISCUSS] Proposed Bylaws changes > > I am +1 on the RFC’s and -1 on the "not directly affiliated with the > proposer's employer” item. > > B. > > > On 13 Feb 2019, at 11:13, Jan Lehnardt wrote: > > > > Sounds fantastic, thanks too for the additional context! I’d love > > for us to lead the way here (yet again). > > > > Best > > Jan > > — > > > >> On 12. Feb 2019, at 20:15, Joan Touzet wrote: > >> > >> Hi everyone, > >> > >> There appears to be general consensus on the RFC process, with no > >> objections to the proposal itself. > >> > >> I'd like to propose the following changes to our bylaws: > >> > >> https://github.com/apache/couchdb-www/commit/8ae3a5a230b1717d7affe23625eeb288635aa542 > >> > >> Quick summary: > >> > >> * Added the RFC proposal process > >> * The RFC will become an official template as part of this > >> * https://github.com/apache/couchdb/pull/1914 adds Bob's request > >> to include a Security section > >> > >> * Proposed a new "qualified lazy majority" approval model for > >> RFCs: > >> * Requires 3 binding +1 votes > >> * Requires more binding +1 votes than binding -1 votes > >> * (NEW) Requires at least +1 binding vote from an individual > >> not directly affiliated with the proposer's employer (if > >> applicable) > >> > >> * Changed URLs to use the new Pony Mail web interface (yay!) > >> > >> While today we are in a great situation where no single entity > >> dominates > >> CouchDB development (to the exclusion of others), I believe this > >> new > >> approval model (just for RFCs) will prevent that from occurring in > >> the > >> future, and will ease a long-standing concern I have held. > >> > >> > >> If there is no strong objection, I will start the VOTE later this > >> week. > >> As this is both creating and amending our official documents, the > >> vote > >> will be a lazy 2/3 majority vote, with binding votes only from PMC > >> members. > >> > >> > >> Why is this so important to me? Recently, on another ASF mailing > >> list, > >> there was a discussion about some of the changes happening in the > >> commercial world, and as it relates to big companies giving back > >> to open > >> source. (You may have read about some competing database projects > >> changing their license, for instance.) > >> > >> Allen Wittenauer graciously allowed me to excerpt his post, which > >> is > >> critical of the Apache Hadoop community, and share it here as a > >> cautionary tale: > >> > >>>> This pretty much ignores the committer hoarding that is > >>>> happening in a lot of ASF projects. It’s something that > >>>> Jeff > >>>> hinted at in a previous reply that I think people > >>>> completely > >>>> missed: > >>>> > >>>>> The obvious reality is that the companies who build service > >>>>> around > >>>>> "pay to call me when it breaks" are very, very often the same > >>>>> companies who hire all the committers, who fund all the dev, > >>>>> who end > >>>>> up in danger when a cloud provider offers their product as a > >>>>> service. > >>>> > >>>> Most of the Hadoop vendors tried to hire as many of the > >>>> committers as they possibly could and was even part of > >>>> some > >>>> PR campaigns (“We have more!” “Ours were first!”) This > >>>> resulted in the community outside of those vendors being > >>>> mostly ignored. This also built a feed
Re: [DISCUSS] Proposed Bylaws changes
I am +1 on the RFC’s and -1 on the "not directly affiliated with the proposer's employer” item. B. > On 13 Feb 2019, at 11:13, Jan Lehnardt wrote: > > Sounds fantastic, thanks too for the additional context! I’d love for us to > lead the way here (yet again). > > Best > Jan > — > >> On 12. Feb 2019, at 20:15, Joan Touzet wrote: >> >> Hi everyone, >> >> There appears to be general consensus on the RFC process, with no >> objections to the proposal itself. >> >> I'd like to propose the following changes to our bylaws: >> >> https://github.com/apache/couchdb-www/commit/8ae3a5a230b1717d7affe23625eeb288635aa542 >> >> Quick summary: >> >> * Added the RFC proposal process >> * The RFC will become an official template as part of this >> * https://github.com/apache/couchdb/pull/1914 adds Bob's request >> to include a Security section >> >> * Proposed a new "qualified lazy majority" approval model for RFCs: >> * Requires 3 binding +1 votes >> * Requires more binding +1 votes than binding -1 votes >> * (NEW) Requires at least +1 binding vote from an individual >> not directly affiliated with the proposer's employer (if >> applicable) >> >> * Changed URLs to use the new Pony Mail web interface (yay!) >> >> While today we are in a great situation where no single entity dominates >> CouchDB development (to the exclusion of others), I believe this new >> approval model (just for RFCs) will prevent that from occurring in the >> future, and will ease a long-standing concern I have held. >> >> >> If there is no strong objection, I will start the VOTE later this week. >> As this is both creating and amending our official documents, the vote >> will be a lazy 2/3 majority vote, with binding votes only from PMC >> members. >> >> >> Why is this so important to me? Recently, on another ASF mailing list, >> there was a discussion about some of the changes happening in the >> commercial world, and as it relates to big companies giving back to open >> source. (You may have read about some competing database projects >> changing their license, for instance.) >> >> Allen Wittenauer graciously allowed me to excerpt his post, which is >> critical of the Apache Hadoop community, and share it here as a >> cautionary tale: >> This pretty much ignores the committer hoarding that is happening in a lot of ASF projects. It’s something that Jeff hinted at in a previous reply that I think people completely missed: > The obvious reality is that the companies who build service around > "pay to call me when it breaks" are very, very often the same > companies who hire all the committers, who fund all the dev, who end > up in danger when a cloud provider offers their product as a > service. Most of the Hadoop vendors tried to hire as many of the committers as they possibly could and was even part of some PR campaigns (“We have more!” “Ours were first!”) This resulted in the community outside of those vendors being mostly ignored. This also built a feedback loop where PMC members promote their coworkers at a significantly higher rate than non-coworkers because the only contributions that were being looked at were the ones that helped their employers. (Anecdotally, coworkers: committer in 6 months, non-coworkers, ~1-2 years, if ever) As a result, the project is a shell of its former self since it was impossible for outsiders to make major, disruptive advancements in the project. Worse yet, Hadoop is now overwhelmingly controlled by one company since two of those vendors were forced to merge. >>> [snip] This is probably the key reason why a lot of companies participate in open source. Maybe if companies didn’t feel the need to hire every single person they could get their hands on to try and control the project, maybe the cloud providers would be more willing to donate man power. As it is, there is little point for anyone outside of a company whose mission is to be “the source” for their project (officially or unofficially) to contribute to non-diverse projects. >> >> From my informal chats with people at ApacheCon 2018 in Montreal, this >> is a hot-button topic. I'd like to get CouchDB out from under this >> cloud. >> >> Again I am NOT ASSERTING that this is where we are today. I think our >> dev community works well together and is not controlled by a single >> entity. I just want to remove the possibility for this sort of abuse to >> occur, and I think that doing so thru the RFC process is the right step >> at this time. >> >> It is in everyone's best interest that RFCs happen, that we have >> consensus agreement on them, and that an open vote happens where
Re: [DISCUSS] Proposed Bylaws changes
Sounds fantastic, thanks too for the additional context! I’d love for us to lead the way here (yet again). Best Jan — > On 12. Feb 2019, at 20:15, Joan Touzet wrote: > > Hi everyone, > > There appears to be general consensus on the RFC process, with no > objections to the proposal itself. > > I'd like to propose the following changes to our bylaws: > > https://github.com/apache/couchdb-www/commit/8ae3a5a230b1717d7affe23625eeb288635aa542 > > Quick summary: > > * Added the RFC proposal process >* The RFC will become an official template as part of this >* https://github.com/apache/couchdb/pull/1914 adds Bob's request > to include a Security section > > * Proposed a new "qualified lazy majority" approval model for RFCs: >* Requires 3 binding +1 votes >* Requires more binding +1 votes than binding -1 votes >* (NEW) Requires at least +1 binding vote from an individual > not directly affiliated with the proposer's employer (if > applicable) > > * Changed URLs to use the new Pony Mail web interface (yay!) > > While today we are in a great situation where no single entity dominates > CouchDB development (to the exclusion of others), I believe this new > approval model (just for RFCs) will prevent that from occurring in the > future, and will ease a long-standing concern I have held. > > > If there is no strong objection, I will start the VOTE later this week. > As this is both creating and amending our official documents, the vote > will be a lazy 2/3 majority vote, with binding votes only from PMC > members. > > > Why is this so important to me? Recently, on another ASF mailing list, > there was a discussion about some of the changes happening in the > commercial world, and as it relates to big companies giving back to open > source. (You may have read about some competing database projects > changing their license, for instance.) > > Allen Wittenauer graciously allowed me to excerpt his post, which is > critical of the Apache Hadoop community, and share it here as a > cautionary tale: > >>>This pretty much ignores the committer hoarding that is >>>happening in a lot of ASF projects. It’s something that Jeff >>>hinted at in a previous reply that I think people completely >>>missed: >>> The obvious reality is that the companies who build service around "pay to call me when it breaks" are very, very often the same companies who hire all the committers, who fund all the dev, who end up in danger when a cloud provider offers their product as a service. >>> >>>Most of the Hadoop vendors tried to hire as many of the >>>committers as they possibly could and was even part of some >>>PR campaigns (“We have more!” “Ours were first!”) This >>>resulted in the community outside of those vendors being >>>mostly ignored. This also built a feedback loop where PMC >>>members promote their coworkers at a significantly higher >>>rate than non-coworkers because the only contributions that >>>were being looked at were the ones that helped their >>>employers. (Anecdotally, coworkers: committer in 6 months, >>>non-coworkers, ~1-2 years, if ever) As a result, the project >>>is a shell of its former self since it was impossible for >>>outsiders to make major, disruptive advancements in the >>>project. Worse yet, Hadoop is now overwhelmingly controlled >>>by one company since two of those vendors were forced to >>>merge. >> [snip] >>>This is probably the key reason why a lot of companies >>>participate in open source. Maybe if companies didn’t feel >>>the need to hire every single person they could get their >>>hands on to try and control the project, maybe the cloud >>>providers would be more willing to donate man power. As it >>>is, there is little point for anyone outside of a company >>>whose mission is to be “the source” for their project >>>(officially or unofficially) to contribute to non-diverse >>>projects. > > From my informal chats with people at ApacheCon 2018 in Montreal, this > is a hot-button topic. I'd like to get CouchDB out from under this > cloud. > > Again I am NOT ASSERTING that this is where we are today. I think our > dev community works well together and is not controlled by a single > entity. I just want to remove the possibility for this sort of abuse to > occur, and I think that doing so thru the RFC process is the right step > at this time. > > It is in everyone's best interest that RFCs happen, that we have > consensus agreement on them, and that an open vote happens where it's > clear that no single party is forcing through changes against the will > of other committed parties. > > -Joan -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
