Thank you Phil for taking time to review the slides and providing such a thorough feedback!
This is incredibly insightful -- I can definitely see the room for improvement and clarifications. I will try and improve the slides and speaker notes based on your feedback. I have a few questions, which I've left inline: On Wed, Dec 19, 2018 at 3:18 PM Phil Steitz <phil.ste...@gmail.com> wrote: > Page 6 - the term "peer-based" seems a little odd to me and it looks > like it is conflating two different things, both of which are > important to us: first - volunteers are *individuals* and second we > have a flat org structure. Related to the first is the idea of > project independence, which is also important (we can't have > projects dominated or controlled by external entities). Missing at > the top-level and usually included is *transparency* - everything > technical, everything required to follow what is happening to the > code is public and anyone interested needs to be able to follow what > is going on via public lists. This is covered more or less in the > notes end elsewhere, but I would personally elevate it to a basic > principle. Traditionally, we have talked about Community, > Meritocracy and Transparency as the pillars. > Ah thanks! This was the main struggle for me to put together, because I couldn't come up with a clear list of basic principles. I found The Six Principles[1] in the ASF website as core beliefs, but not much else was written about them. Also, the same page refers to meritocracy as a basic principle[2]. I think Community, Meritocracy and Transparency really capture the philosophy of the Apache Way. I will change that slide to include all these as top-level principles. Perhaps I'll propose an update to the Philosophy section[1] of ASF website, that presents these three as the basic principles to avoid confusion. Does that sound fine to everyone? Page 12 - I don't like the little check boxes limiting what > committers (or any community member, for that matter) are > responsible for. The only real difference between PMC members and > committers is that PMC members have binding votes on release and > committer votes. Committers absolutely do need to think about legal > / IP and security issues. And they should be involved in mentoring > and encouraging contributors. And all community members should have > a voice in "rules and customs" for the project. PMC members are not > "managers" in the typical sense. They are ultimately accountable to > the Board and have binding votes, but they need to serve their > communities. And committers are not just coders. > I think these are good points. The intention of this slide is not to present it as a hard truth, but more as a general guideline, and especially to highlight that the PMC is ultimately accountable to the Board if any legal/governance issues arise, and they are in charge of discussing private matters such as new committers, and critical security bugs. To express that, I think it may be useful to replace the "X"-marks with "maybe", and give a detailed explanation in the speaker notes. How does this sound? > Page 14 - I am not sure I agree with the last item. People leave > projects all the time and there is no expectation that they "explain > why they are leaving." > This is true. I agree that explaining why is not necessary. My idea was to encourage people to set appropriate expectations about their involvement. Perhaps replace that with "Be considerate: Set appropriate expectations about your involvement". How does that sound? > Page 15 - I don't think this is what you mean, but the slide makes > it looks like the primary responsibility of each group is the thing > on the right, which it isn't. I would also be careful with the > "don't be a bottleneck" idea. Committers (or PMC members) should > not feel like they have to quickly review all contributions. They > are volunteers. If PRs go for a long time without getting reviewed, > more volunteers may be needed or the community may simply not be > interested in them. > That's a good point as well. I was trying to give some tips for participating and contributing to a project in each role in a day-to-day basis. I will rephrase the tips, and add some more detailed explanations in the speaker notes. Thanks a lot, I appreciate all the feedback! : ) -A [1] https://www.apache.org/foundation/how-it-works.html#philosophy [2] https://www.apache.org/foundation/how-it-works.html#meritocracy -- *Aizhamal Nurmamat kyzy* Open Source Program Manager 646-355-9740 Mobile 601 North 34th Street, Seattle, WA 98103
