BCC: private@ The bulk of this discussion should proceed with good intent on dev@ with a separate thread on private@ only if needed.
I have prepared a set of links to documentation about the Apache Way that is worth reviewing: https://petri.apache.org/way <https://petri.apache.org/way> Hierarchy in an Apache project should be as flat as possible. On dev@ an open discussion about the Apache Pulsar Community should be proceed about: (1) Communications - How do the members of the community let the community know what they have been doing? - How should that be done to show vendor neutrality? The standard answer is to mention progress on dev@. Other solutions are possible and anyone who is interested should be able to contribute and earn merit in the community. If community volunteers produce a Newsletter that should not bother the PMC. (2) Meetups - There are a number of questions here and I am likely to miss a few. - There has been a semi-official Meetup organized by Sree Vadi since Incubation. - Others wish to his Meetups. - It can only benefit the whole of the Pulsar Community to communicate all meetups where the commits can know about it. While it might appear that everyone is far apart I think that people should make one or more proposals. Then there can be a discussion without summary veto from PMC members. Sometimes Consensus is hard. All The Best, Dave > On Aug 20, 2021, at 12:46 AM, Rajan Dhabalia <rdhaba...@apache.org> wrote: > > *I think the Apache project should avoid vendor-specific branding, in that > way users will have a clear understanding about what they can receive from > the free Apache project. In support of that, the Apache project should be > driven by the community/PMC who are the real contributors to the project > and let every member participate in each decision process. Therefore, I > feel subcommittees will not give justice to every PMC member of the project > and may create confusion to the users about the ownership and branding of > the project. Therefore, we should address all those concerns that are > misleading users about project branding or make users think that the Apache > project is driven by a specific vendor. I think ASF branding policy > <https://community.apache.org/projectIndependence.html> summarises it very > well: “Third-party software product must be clearly branded such that, > users clearly understand the different sources for software products such > as Apache Foo (from the ASF) and BigCo SuperThing, Powered By Apache Foo > (from BigCo).”Thanks,Rajan* > > On Thu, Aug 19, 2021 at 4:49 PM Matteo Merli <mme...@apache.org> wrote: > >> On Thu, Aug 19, 2021 at 5:35 AM Jonathan Ellis <jbel...@gmail.com> wrote: >>> >>> Moving back to dev. >>> >>> Since it seems like there's some confusion on this point, it's perfectly >>> normal for PMC discussions around new proposals with decision-making >>> authority by the PMC to take place on the public dev list. The private >>> list is only necessary when confidentiality is required, and the dev list >>> allows non-PMC voices to be heard more readily as well as promoting >>> transparency on how consensus was reached. >>> >>> I am not aware of any ASF policy that would prohibit subcommittees like >>> this. (I'm not aware of precedent in starting one either, but as Aaron >>> pointed out, this *is* common at similar foundations with similar >>> governance goals to the ASF, and there's no reason we can't >> cross-pollinate >>> good ideas.) >> >> Jonathan, >> >> If you keep switching from private@ to dev@ list, most of the people >> on dev@ list will be out of context of the replies from other PMC >> members on the private list. >> >> Your proposal of subcommittees has already raised strong concerns from >> 4 PMC members, with no one speaking in favour of it. >> >>> I am not aware of any ASF policy that would prohibit subcommittees like >>> this >> >> The part of your proposal of including representatives of vendors in >> these subcommittees goes directly against the spirit of these >> guidelines: https://community.apache.org/projectIndependence.html >> >> Matteo >> >> -- >> Matteo Merli >> <mme...@apache.org> >>
