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
>
>

Reply via email to