Thanks for taking my comment the way it was intended (to fuel productive debate) :-)
You are right that VPs don't set policy but they should write policy and submit to the board for tuning and/or approval/rejection. In turn those VPs will typically consult with their committee members. It really should be bottom up. This scales well. Looking to a board of 9 overworked directors to do everything for 150+ projects (and potentially adding podlings based on some IPMC recommendations) does not scale. That being said, you are correct the release policy is really a legal issue and thus is under VP Legal, with VP Infra needing to approve any policy since it has impact on what infra needs to deliver. Fortunately Jim has indicated he feels he owns much of this as VP Legal so you are off the hook and made your point well - a good result for you I think :-) Here's to Jim for stepping up and offering to try to heard the sheep on this one. Ross -----Original Message----- From: David Nalley [mailto:da...@gnsa.us] Sent: Tuesday, January 13, 2015 9:37 AM To: general@incubator.apache.org Subject: Re: What is "The Apache Way"? On Tue, Jan 13, 2015 at 11:23 AM, Ross Gardler (MS OPEN TECH) <ross.gard...@microsoft.com> wrote: > Well, David, I'm afraid you are the authoritative source on the policy you > use as an example. :) Well - I suppose I did open myself up for that. > If it's not documented and that's a problem then it's *your* problem. You > could (given even more time to volunteer to the ASF, solve it however you > like (e.g. Write the doc, ask the community to write it, ask for budget to > have a contract write it, something else), but it's you and the infra team > that own this. > So, infra has a number of policies - like not keeping more than the current release on dist, giving us a heads up if your artifacts are going to be more 1GB, but they are largely centered around efficient operation of infrastructure, and not Apache Doctrine. Defining (and by extension enforcing) Apache Doctrine, means that infrastructure becomes the Foundation's policeman, at least in certain matters. Infrastructure, derives authority from the office of the President. Based on my reading of the bylaws, and the almost recent discussion around Brand issues - I walked away with the fact that the office of the President may not be able to set binding policy on projects. (differentiated from binding policy of how you may use resources of the Foundation). In the specific example I referenced - which came up in May (on board-private because there was a security issue related to it) I was told to carry the issue to the public board mailing list after the security issue was dealt with because it needed discussing. It did get discussed - release policy (which I think was later declared to be a legal issue), which is a board committee. After that thread revealed that there was no written policy, I explicitly asked several directors (individually) if that was within my scope to define, so as to remove the ambiguity and walked away with the impression that most of them felt it was not within my level of authority. > I hope you won't take this personally, its not meant that way. As a volunteer > you do a fantastic job and we are all immensely grateful. However, you did > feed me a perfect way to illustrate the point I've been trying to make when > highlighting docs and saying "patches welcome". > Not at all. My assumption was that 'setting binding policy on projects' was something specifically excluded from my level of authority, as an officer derived from the Office of the President. If that is not the case, I am happy to define and publish such things within the realm of infrastructure. > Perhaps it is time we hired a contractor to draw up the one document of truth? > > I'm working on the 2015 budget now. Any volunteers to own this? Ownership is > ensuring that the individual gets access to all the appropriate VPs and that > those VPs are able to provide the necessary input. > I think Marvin could manage this well (yes, this is me pushing you in front of the bus, Marvin. My apologies). Failing that, I'm happy to tackle management of that. --David --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
