Hello All: The issue seems to balance control against growth (along the lines Apache wants to foster).
A way to do this would be to ensure there is a clear Apache entity, where the ideals and standards can be learned on these topics. As new issues arise, positions should be considered and defined in a timely manner, ordered by importance and this information should be easily accessible to those that are interested, so they can learn for themselves Apache's position on important topics. This doesn't take a lot of overhead, just clarity. Those that are sanctioned as "members" of Apache help define these ideals, and once published will be the stance AT THAT TIME of Apache. Apache can change its mind. Another important aspect of this is taking feedback from all-comers. It is valuable information for future improvement and adaption, allowing Apache to not become tone-def. An analogy of this would be, anyone can say anything about you they want, but if you are accessible and responsive, any position can be clarified easily by anyone interested. One does not have to chase down all the rumor-mongers and libelists. Anyone interested in investigating can find out for themselves exactly what Apache's stance is. On this particular topic, it is important for people to make a living, and understanding how participation in Apache can help or harm that is a really important subject. It is also germane to Apache's role in society and how it can optimize its effect. It is impossible to police everyone, but if Apache's stance can be easily clarified, then anyone can discern and execute for themselves, without central control, or a complex bureaucratic structure. The beauty of Apache, is it is an idea, so it is more easily defended than many other things. If the ideals are well-formed and clarified, then contribution and participation can be maximized even from those that are not "official" as well as allowing novel approaches and growth that I believe Apache would seem to foster. $0.02, Travis On Fri, Dec 06, 2019 at 09:19:05AM -0800, Austin Bennett wrote: > The bits on mentorship make some sense, although I am confused. If about > who is allowed/endorsed to speak on behalf of the ASF, then: > > * Should only speakers at events be of a condoned status (how are they > vetted)? > or: > * Would a required minimum number of mentors (PMC/Foundation members) be > required in attendance, to be able to correct mis-messages? > or more extreme: > * Should every piece of content be recorded and reviewed, and if > insufficient then the group should be discredited (that is extreme and > unlikely, but I think you see the example). > > ^ The first two perhaps are things that should then also be included in the > report of an event. > > Otherwise, it seems without the above invites much more bureaucracy without > actually doing much to solve/prevent the problem that seems to concern > people? > > > > > > > On Fri, Dec 6, 2019 at 8:37 AM Rich Bowen <rbo...@rcbowen.com> wrote: > > > > > > > On 12/4/19 5:56 PM, Issac Goldstand wrote: > > > > > > On Dec 4, 2019 22:15, Rich Bowen <rbo...@rcbowen.com> wrote: > > > > > > > > > . But I've learned from Fedora user > > > groups that allowing any random stranger to start up a group, using > > our > > > Trademarks, to promote whatever message comes into their head, is > > > *going* to bite us in the butt, sooner rather than later. > > > > > > Are these from groups that are managed/overseen by RedHat? Can you share > > > more information about what you've learned the hard way? Because maybe > > > the way I suggest below is objectively wrong, and if so I'd rather > > > understand the faulty reasoning on my part sooner, rather than later... > > > > I'm reluctant to tell stories on a public list, particularly when almost > > all of the stories are third-hand. But the lesson learned is that when > > you give someone a title, there's a chance that they will take it as a > > fiefdom - a little kingdom where they rule, call the shots, and don't > > have to answer to anyone else. > > > > > > > > I've mentioned before that my standpoint is that it's impossible to > > > properly police every fan driven event out there, and I seem to recall > > > that use of a trademark by fans in a manner that isn't making profits is > > > generally considered acceptable use. Is it not therefore a good-enoungh > > > way to start by allowing (CTR instead of RTC as it were)? > > > > Absolutely. We don't even *want* to police every fan event. And we want > > a LOT of fan events. The nuance is the moment we give our Official Seal > > Of Approval to a group/event/organization, then we are implicitly > > approving their message, and that's where we introduce audience confusion. > > > > > > > > > > > This is *NOT* about the Indore group and their recent event. Rather > > > it's > > > about the future. The groups currently out there are full of > > > experienced > > > Apache people. All well and good. The second wave will be full of > > > people > > > wanting to promote their business, or their personal brand, using our > > > name, and spreading misinformation about Apache under our official > > > banner. > > > > > > Once there is enough traction in the user groups that we can see a clear > > > difference between user (fan) groups that are promoting Apache vs groups > > > that are using the name to promote themselves, we could go with the > > > carrot and stick. The carrot is recognition and support by the ASF for > > > the good players, and the stick is trademark abuse complaints and > > > threats of legal action to those that don't. > > > > > > Or even just the stick. > > > > > > Because the carrot means having to make rules. And rules make life > > > harder for volunteers. Pulling off a successful meetup/event and > > > maintaining a successful community is hard enough without rules. > > > Sometimes rules are unavoidable, and so be it, but let's keep the > > > barrier of entry as low as possible for the amazing folks who are trying > > > to raise positive awareness of what we do here. > > > > > > > > > We *cannot* allow this to happen. To do so would be a dereliction of > > > our > > > duty as a PMC. We must plan for the bad actors, even while enabling > > the > > > good actors. > > > > > > Can we really expect to catch all the bad actors, long term? Especially > > > since anyone can go to meetup.com, register The Official Apache > > Software > > > Foundation Meetup of Somecity, Somecountry, tack on the feather logo, > > > and run with it with us none the wiser... Yes, we'd react swiftly and > > > forcefully once we *did* catch on, but we can't stop it from happening. > > > We can't monitor everything. > > > > No, we cannot expect to catch them all. But if, as I say above, give any > > group our Official Seal Of Approval, and give them space on OUR website, > > we are *explicitly* endorsing whatever they say. That's the line that > > cannot be crossed. > > > > > > > > We've gone 20 years without real traction in local small events that we > > > are happy with. Suddenly in the past week I'm seeing more interest than > > > we've had in years. Yes, we should have a plan for bad actors, but not > > > at the cost of stifling potentially good ones. > > > > +1 > > > > > I'm not entirely sure what I'm proposing, but I think that > > > requiring, at > > > this stage, at least one Member to be involved in the creation and > > > mentoring of a new group, is a reasonable path. > > > > > > Just remember that it will be only mentoring. > > > > > > Not every geographic location has a member (or even PMC member) that can > > > supervise the content actually delivered there. Unlike the incubator > > > where the mentors see everything happening in-code and on-list, for > > > offline events in different languages and locations, the level of > > > supervision needed to truly monitor the group is simply not scalable. > > > > > > I'd be willing to be such a mentor - given the above caveats - if comdev > > > seems it helpful. > > > > I would think that geographically (or at least time-zone) close mentors > > would be preferred, but, yes, failing that, we definitely need others to > > step in. > > > > -- > > Rich Bowen - rbo...@rcbowen.com > > http://rcbowen.com/ > > @rbowen > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
