On Tue, Dec 6, 2016 at 11:45 AM, Rich Bowen <rbo...@rcbowen.com> wrote:
>
>
> On 12/06/2016 01:26 PM, Roman Shaposhnik wrote:
>> I'd like to strongly echo Bertrand here. To me, ComDev is first, and foremost
>> an ASF's braintrust if you will of things that have to do with
>> community development,
>> governance and all around non-coding. It is a place to come and ask
>> for advice, etc.
>>
>> Of course, anything we can do to clean up documentation or provide
>> better guidance
>> is welcome, but I don't think ComDev is responsible for community
>> development of ASF
>> the same way that Rich is responsible for it at his day job.
>
> So, to quote Tyrion Lannister, we drink and we know things?
That's a very, very good way to put it!
> Well, the point of this thread is that I think that's not enough any
> more. It's taking the easy way out, and will eventually lead to an ASF
> where more and more projects are satellites, disconnected from the
> central ASF community, and we no longer share any commonality between
> ASF projects.
Good point, but to answer another point brought by Daniel lets look at
what this PMC's charter says:
============================================================
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with coordinating community development
efforts.
============================================================
that last part "charged with coordinating community development efforts"
has a very important keyword -- coordinating. We ARE a coordinating body
according to our charter. What it translates into for me is helping
those interested
in community development within each project find common tools, approaches
and techniques. Just like with IPMC -- it is a pull model, rather than
a push one.
Now, nothing prevents us from clarifying the charter (or going above and beyond
it) but I just wanted to point out where we stand.
> Any community (or company, or country, or whatever) that grows at the
> rate that the ASF is growing risks losing its identity unless culture is
> actively preserved - unless community is actively developed.
I'd argue that establishing initial culture is the job of IPMC (mostly
via mentors).
Monitoring the culture of TLPs is the job of the board and membership.
> We have been entrusted by the board to do that community development.
Perhaps you'll look at it as semantics -- but my read is that we've been
entrusted with *coordination* of said community development. So yes:
"we drink and we know things" until such a point that a charter gets clarified.
> I want the ASF to still be here in 50 years, and I want the ASF in 50
> years to be something that we would recognize. It's not enough to drink
> and know things - though I recommend both of these things highly. We
> need to be actively training the young'uns to run with our passion when
> we aren't there any more.
Once again - young'uns in terms of the project age is the IPMC's job.
young'uns in terms on n00bs coming to existing ASF projects is individual
PMC's job.
So what's left for ComDev? Policing?
That later point is why I felt compelled to pile on top of Bertrand was saying.
I really don't want ComDev to become the owners of "The Apache Way".
That's membership's job. Even less do I want ComDev to get in the business
of policing.
> No doubt someone will say that this is the Incubator's job. The
> Incubator is there to train projects at onboarding.
No way! That's just not the case given the IPMC charter. I really strongly
disagree with you restricting it that way.
> We are here to
> develop community, and encourage projects to continue doing what the
> Incubator taught them, and to draw them deeper into the ASF family. In a
> sense ComDev picks up where the Incubator leaves off. And then at some
> point we hand off to Attic. It's a circle of life thing.
See. That's where my problem with your proposal really begins -- the PMC is
really either ready or not. If it is ready -- it MUST be capable of
self-managing.
That includes "training the young'uns" and proliferating ASF culture. And if PMC
needs resources and/or help -- sure there will be ComDev ready to help.
"Apache Way" governance model is appealing precisely because of the same reason
that US federal model is: there's a non-negotiable culture statement
called Constitution.
The rest is left up to the states. And yes Feds can create programs to
get state's attention
(mostly via financial incentives) but other that that states are free
to define their own
policies (still within what's allowed by the constitution).
But ok, you're clearly increasing the charter of ComDev. That's
actually fine as long as the
principle of PMC independence I stated above holds.
||| * Increase community diversity. Identify projects that are monocultures
||| (or near to them) and help them actively pursue broader community diversity.
If this is -- "hey, we've noticed your community can benefit from increased
diversity here are some tools to help with that" -- I'm +1. If this is
a policing
function for the board I'm -1 until that time that policing becomes
part of ComDev
charter.
||| * Develop tools (documentation, training materials, and software tools)
||| that projects can use to promote themselves and attract new
||| participants. (Participants is a very broad term here, and does not
||| refer only to code jockeys.)
We are doing some of it already -- so I'm not sure what are you proposing.
More of what's already happening? Some metrics to make sure there's
content being produced at a given rate?
||| * Educate projects on the Apache Way, so that they can more richly
||| experience the organization that they have attached themselves to.
||| Identify projects that appear to be operating outside of the Apache Way,
||| and gently, kindly, lead them back to the light.
Again, seems like some of us (I can definitely speak for myself) are aready
doing a lot of this. What's new that's being proposed?
||| * Strengthen the bonds between projects and the larger Foundation.
||| Defining this is a whole other thread, but means several things to me.
||| Identify projects that are satellites and build ties back to the
||| "family", in terms of participating in events, participating in
||| governance discussions, having adequate membership representation on the
||| PMC, and so on.
Sounds good as an applehood and motherpie until it gets to "hey, we've noticed
your project could really benefit from playing nicely with that other
project over
there -- go do it!" Hopefully it won't get to that -- but like I said
-- projects should
be free to like or not like other projects. Heck -- they should be
free to fork if
they so desire. As long as they run truly open, transparent communities -- who
are we to barge in and tell them otherwise?
||| * It's not about marketing, but we should be working very closely with
||| marketing (press@) to promote what our projects are doing, and promote
||| the idea of the ASF as a place where innovation happens, thus drawing in
||| an engaged and excited participant community.
Agreed. But, in terms of practical steps -- what is being proposed?
||| * Internal promotion and cheerleading. Marketing is outward facing.
||| Community development is somewhat inward facing. Many of our projects
||| have no idea what other projects are doing, and don't care. Doing a
||| degree of internal cheerleading, along with the education, is critical
||| for building exprit de corps.
Huge +1. But at the same time -- the best way to help here is to lead
by example.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
