> > Please keep in mind that you are also "ASF people," as is the entire Spark > community (users and all)[4]. Phrasing things in terms of "us and them" by > drawing a distinction on "[they] get in a fight on our mailing list" is not > helpful.
<whine>But they started it!</whine> A bit more seriously, my perspective is that the Spark community and development process works very well and quite smoothly. The only significant strains that I have witnessed during the time in which Spark has been Apache Spark have been when "ASF people" who otherwise have neither contributed to Spark development nor participated in the Spark community parachute in to tell us that we are doing things wrong and that we must change our practice in order to conform to their expectations of "The Apache Way". Sometimes those admonitions are based on actual Apache bylaws and/or legal requirements, and we need to take them seriously. Other times they have seemed more subjective and have felt more like meddling or stirring up trouble in the community and with a process that is actually working very well. On Tue, Jul 14, 2015 at 10:09 AM, Sean Busbey <bus...@cloudera.com> wrote: > Responses inline, with some liberties on ordering. > > On Sun, Jul 12, 2015 at 10:32 PM, Patrick Wendell <pwend...@gmail.com> > wrote: > >> Hey Sean B, >> >> Would you mind outlining for me how we go about changing this policy - >> I think it's outdated and doesn't make much sense. Ideally I'd like to >> propose a vote to modify the text slightly such that our current >> behavior is seen as complaint. Specifically: >> > > > >> - Who has the authority to change this document? >> > > It's foundation level policy, so I'd presume the board needs to. Since > it's part of our legal position, it might be owned by the legal affairs > committee[1]. That would mean they could update it without a board > resolution. (legal-discuss@ could tell you for sure). > > >> - What concrete steps can I take to change the policy? >> > > The Legal Affairs Committee is reachable either through their mailing > list[2] or their issue tracker[3]. > > Please be sure to read the entire original document, it explains the > rationale that has gone into it. You'll need to address the matters raised > there. > > > >> - You keep mentioning the incubator@ list, why is this the place for >> such policy to be discussed or decided on? >> > > > It can't be decided on the general@incubator list, but there are already > several relevant parties discussing the matter there. You certainly don't > *need* to join that conversation, but the participants there have overlap > with the folks who can ultimately decide the issue. Thus, it may help avoid > having to repeat things. > > > >> - What is the reasonable amount of time frame in which the policy >> change is likely to be decided? >> >> > I am neither a participant on legal affairs nor the board, so I have no > idea. > > >> We've had a few times people from the various parts of the ASF come >> and say we are in violation of a policy. And sometimes other ASF >> people come and then get in a fight on our mailing list, and there is >> > > > Please keep in mind that you are also "ASF people," as is the entire Spark > community (users and all)[4]. Phrasing things in terms of "us and them" by > drawing a distinction on "[they] get in a fight on our mailing list" is not > helpful. > > > >> back and fourth, and it turns out there isn't so much a widely >> followed policy as a doc somewhere that is really old and not actually >> universally followed. It's difficult for us in such situations to now >> how to proceed and how much autonomy we as a PMC have to make >> decisions about our own project. >> >> > Understanding and abiding by ASF legal obligations and policies is the job > of each project PMC as a part of their formation by the board[5]. If anyone > in your community has questions about what the project can or can not do > then it's the job of the PMC find out proactively (rather than take a "ask > for forgiveness" approach). Where the existing documentation is unclear or > where you think it might be out of date, you can often get guidance from > general@incubator (since it contains a large number of members and folks > from across foundation projects) or comdev[6] (since their charter includes > explaining ASF policy). If those resources prove insufficient matters can > be brought up with either legal-discuss@ or board@. > > If you find out of date documentation that is not ASF policy, you can have > it removed by notifying the appropriate group (i.e. legal-discuss, comdev, > or whomever is hosting it). > > > [1]: http://apache.org/legal/ > [2]: http://www.apache.org/foundation/mailinglists.html#foundation-legal > [3]: https://issues.apache.org/jira/browse/LEGAL/ > [4]: http://www.apache.org/foundation/how-it-works.html#roles > [5]: http://apache.org/foundation/how-it-works.html#pmc > [6]: https://community.apache.org/ > > -- > Sean >
