Re: Looking for community development stories

2020-01-21 Thread Kenneth Knowles
I've done a bit of evangelism on this topic:

https://blogs.apache.org/comdev/entry/an-approach-to-community-building

https://www.youtube.com/watch?v=3409SA-QpdE (Apache@Google summit. You were
there, but here's a vid)

My favorite highlights (maybe from the above but not sure if I said it
explicitly; I'm making them up without re-reading or re-watching)

 - code reviews are a chance to build community (and make friends ?!?)
 - inclusion of non-code contributions critical and needs highlighting
because it isn't highlighted by default
 - transparency of PMC expectations makes the project more self-serve /
empowers contributors
 - focusing PMC discussions on individuals and the above expectations
increases fairness and clarity
 - encouragement emails have an impact
 - committers stay engaged (after team/job changes)

My phrasing in the blog post was misconstrued by some popular press as a
presentation of a problem, when I meant to be celebrating some success. So
adjust if you use any of it :-)

Beam entered incubation as a Google donation and has grown to be much more
than that. The balance isn't perfect, but it is better, so I think it is a
success story so far.

Having followed a number of Apache dev lists and mentoring a couple
still-incubating projects, I would simply emphasize use of the dev@ list
for public development discussion/decisions. The people in these projects
are smart, so they understand the formality expectations when you say "use
the dev@ list" and yet they just don't do it. Why? Mental models, culture,
efficiency, incentives? A whole talk on why it is actually important, and
not just an ASF habit of yesteryear would go a long way, for both podlings
and TLPs that I have followed.

Kenn

On Tue, Jan 21, 2020 at 5:30 PM Craig Russell  wrote:

> Hi,
>
> I'm working on a presentation to the Huawei Developer Conference in
> Shenzhen February 11 on the subject of "Growing Communities The Apache Way".
>
> I'd like to share with the audience some stories of Apache Projects that
> have grown their communities, either in the incubator or after becoming a
> top level project.
>
> What I'd like is some facts to discuss, e.g. community makeup before
> entering incubator, community exiting incubator, any special actions done
> by the community to encourage growth, etc. With some details, I can share
> the projects' successes with the developers at the conference.
>
> Any help is very appreciated. I'll need any input by Friday January 31 (10
> days from now; a day before FOSDEM).
>
> Thanks,
>
> Craig
>
> Craig L Russell
> c...@apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


Re: Please add Beam logo to RedBubble + stickers/swag for ApacheCons

2019-09-24 Thread Kenneth Knowles
Right again. I had failed at using svn. Should all be committed now.

Kenn

On Fri, Sep 6, 2019 at 2:09 AM Mark Thomas  wrote:

> Kenneth,
>
> Please check your working copy.
> beam-1.svg and beam-2.svg are no longer present in the repo.
>
> Mark
>
> On 06/09/2019 06:32, Kenneth Knowles wrote:
> >
> >
> > On Mon, Sep 2, 2019 at 2:21 PM Mark Thomas  > <mailto:ma...@apache.org>> wrote:
> >
> > On 20/08/2019 05:53, Kenneth Knowles wrote:
> > > I was looking to order some stuff and it seems that there is
> something
> > > wrong here. If you flip through the images, they are this:
> > >
> > > 1. "B" with the word "beam" to the side of it
> > > 2. "B" alone
> > > 3. "B" with the words "Apache Beam" circling the base of it
> > >
> > > The SVGs and PDFs match this. But the raster images have problems.
> > Both low
> > > and high res raster images are variations of version 3 with
> > different font
> > > colorings.
> > >
> > > I really want the "B" all on its own, aka what you would think was
> > version
> > > 2.
> >
> > 2 is the same as three but with the words "Apache Beam" in white.
> There
> > is no logo just with "B" alone.
> >
> >
> > Ah, I see. Missed that, against the transparent background. Thanks for
> > the tip.
> >
> > It seems only version 1 is actually a logo
> > from https://beam.apache.org/community/logos/. I've taken the liberty of
> > making versions 1-3 the versions found there, in the order found there.
> > I moved the other logos to 4 and 5. (changes to SVN not yet apparent on
> > the page)
> >
> > Kenn
>
>


Re: Please add Beam logo to RedBubble + stickers/swag for ApacheCons

2019-09-05 Thread Kenneth Knowles
On Mon, Sep 2, 2019 at 2:21 PM Mark Thomas  wrote:

> On 20/08/2019 05:53, Kenneth Knowles wrote:
> > I was looking to order some stuff and it seems that there is something
> > wrong here. If you flip through the images, they are this:
> >
> > 1. "B" with the word "beam" to the side of it
> > 2. "B" alone
> > 3. "B" with the words "Apache Beam" circling the base of it
> >
> > The SVGs and PDFs match this. But the raster images have problems. Both
> low
> > and high res raster images are variations of version 3 with different
> font
> > colorings.
> >
> > I really want the "B" all on its own, aka what you would think was
> version
> > 2.
>
> 2 is the same as three but with the words "Apache Beam" in white. There
> is no logo just with "B" alone.
>

Ah, I see. Missed that, against the transparent background. Thanks for the
tip.

It seems only version 1 is actually a logo from
https://beam.apache.org/community/logos/. I've taken the liberty of making
versions 1-3 the versions found there, in the order found there. I moved
the other logos to 4 and 5. (changes to SVN not yet apparent on the page)

Kenn


Re: Please add Beam logo to RedBubble + stickers/swag for ApacheCons

2019-08-19 Thread Kenneth Knowles
I was looking to order some stuff and it seems that there is something
wrong here. If you flip through the images, they are this:

1. "B" with the word "beam" to the side of it
2. "B" alone
3. "B" with the words "Apache Beam" circling the base of it

The SVGs and PDFs match this. But the raster images have problems. Both low
and high res raster images are variations of version 3 with different font
colorings.

I really want the "B" all on its own, aka what you would think was version
2.

Kenn

On Wed, Aug 7, 2019 at 5:10 PM Aizhamal Nurmamat kyzy 
wrote:

> Thank you very much :)
>
> On Wed, Aug 7, 2019 at 1:13 PM Sharan Foga  wrote:
>
> > Hi Aizhamal
> >
> > I've added Beam to the sticker list and noted to use version 2 of the
> logo.
> >
> > Thanks
> > Sharan
> >
> > On 2019/08/07 19:55:21, Aizhamal Nurmamat kyzy 
> > wrote:
> > > Hello everyone,
> > >
> > > Could you please also add Apache Beam to RedBubble? Here is our logo:
> > > http://apache.org/logos/#beam
> > >
> > > Couldn't edit the ComDev Wiki myself, but would like to request the
> > > stickers/swag as well. If possible, can we use Version 2 for the
> stickers
> > > from http://apache.org/logos/#beam ?
> > >
> > > We will also send you the #LoveApache Beam logo soon.
> > >
> > > Thank you tons,
> > > Aizhamal
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>


Re: Focused effort on Apache Way education

2019-07-17 Thread Kenneth Knowles
On Wed, Jul 17, 2019 at 9:20 AM Joan Touzet  wrote:

> Hey y'all,
>
> On 2019-07-17 7:53, Jim Jagielski wrote:
> >> On Jul 17, 2019, at 2:56 AM, Bertrand Delacretaz <
> bdelacre...@apache.org> wrote:
> >>
> >> On Wed, Jul 17, 2019 at 1:11 AM Dave Fisher 
> wrote:
> >>> ...I’d like to see the Apache Way described like Euclidean Geometry
> >>
> >> I have no clue what this would look like but I'd love to see a blog
> >> post of yours describing that vision.
> >>
> > +1
>
> This was where I was aiming with my original post on board@ (which many
> of you may not be able to see).
>
> I mentioned I often refer to Shane's summary because it's simple,
> concise, and includes the why as well as the what. But I'm aware that
> it's just one viewpoint - the website makes that perfectly clear, too.
>
> It's been said to me that a lot of The Apache Way can't be written down,
> and I would like to challenge that assertion. I'd also like the people
> who claim to know the Way best to work as hard as possible on that, too.
>

We need all those voices of how people interpret The Apache Way. And as
> Dave hints, we can triangulate its essence with more and more
> descriptions. I think it'd be premature to try for that triangulation
> without interested parties working on capturing it for themselves first,
> revised for a 2019 perspective.
>

Exactly. Sometimes when it is said it cannot be written down, it can mean
that it cannot be written down simply and declaratively. Or that it cannot
be expressed by being written just once or one way or by one or a few
people. The concepts in a novel, an ethnography, or a biography, or even
short parables, for example, cannot be simply extracted and written as
declarations. The practices of a culture cannot be described fully either,
nor transmitted by reading. It may be that the large corpus of writing and
slideshows and talking about The Apache Way is a great way to, in fact,
write it down. And IMO in such a situation it is important to keep writing
about it, and have new people keep writing their take, and to share stories
about it. Etc. And of course, it should be expected to constantly change.

Kenn



>
> -Joan "dust yourself off and try again" Touzet
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


Re: Request for Reviewers for Community Track at ApacheCon NA Las Vegas

2019-05-28 Thread Kenneth Knowles
Is there a recommendation for talks that seem to be in the wrong category?

Kenn

On Mon, May 27, 2019 at 10:44 AM Sharan Foga  wrote:

> Thanks very much for sending out the reminder to our reviewers Swapnil! :-)
>
> On 2019/05/27 08:42:05, Swapnil M Mane  wrote:
> > Hello team,
> >
> > Thanks for showing interest in reviewing the Community track at ApacheCon
> > NA.
> > Please log in to CPF System [1], and visit *Review Submission* section to
> > review the submissions.
> >
> >
> > [1] https://asf.jamhosted.net/cfp.html
> >
> >
> > - Best Regards,
> > Swapnil M Mane,
> > ofbiz.apache.org
> >
> >
> >
> > On Sat, May 4, 2019 at 1:41 AM Sharan Foga  wrote:
> >
> > > Hi George
> > >
> > > Great to hear from you! As long as you've requested to be a reviewer
> via
> > > the CFP system itself you'll be on the list.
> > >
> > > Thanks
> > > Sharan
> > >
> > > You'll need to request to be a reviewer - I'm not sure how it works for
> > > specific tracks
> > >
> > > On 2019/05/03 12:47:28, George Percivall  wrote:
> > > > Sharan,
> > > >
> > > > Please sign me up for as a volunteer to review the submissions for
> the
> > > Geospatial Track.
> > > >
> > > > George
> > > >
> > > >
> > > >
> > > > > On May 1, 2019, at 4:16 PM, Sharan Foga  wrote:
> > > > >
> > > > > Hi All
> > > > >
> > > > > The CFP for ApacheCon NA, Las Vegas will be closing soon so I am
> > > looking for some volunteers to help review and rate the Community track
> > > submissions.
> > > > >
> > > > > If you are interested in helping out then please follow the submit
> a
> > > talk link to login to the CFP system for ApacheCon NA, Las Vegas and
> then
> > > click on the link to request to become a reviewer.
> > > > >
> > > > > https://asf.jamhosted.net/cfp.html
> > > > >
> > > > > Thanks
> > > > > Sharan
> > > > >
> > > > >
> > > > >
> -
> > > > > 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
> > > >
> > > >
> > >
> > > -
> > > 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
>
>


Re: Roadshow Seattle

2019-05-15 Thread Kenneth Knowles
Sign me up to help as well. I'd also just love to meet face to face.

Kenn


On Wed, May 15, 2019, 09:40 Andrew Musselman 
wrote:

> Thanks Trev.
>
> Absolutely Aizhamal, anyone else interested in helping in any way please
> let us know.
>
> Downtown seemed good since Fremont is a quick trip from Google and there
> are so many HQs in SLU. Or maybe that fancy Starbucks in Cap Hill; lots of
> big tables there.
>
> Looking forward to it; tentatively look at next week or the following?
>
> On Wed, May 15, 2019 at 07:12 Trevor Grant 
> wrote:
>
> > I also told him in person I would support w learnings from Chicago.
> >
> >
> >
> > On Wed, May 15, 2019 at 2:29 AM Ross Gardler 
> wrote:
> >
> > > Will do, Andrew and I decided we'll meet downtown for a chat. No time
> set
> > > yet. Then come back here with a proposal. If anyone else wants to join
> us
> > > for coffee drop us a note offlist (keep organizational noise down).
> > >
> > > Get Outlook for Android
> > >
> > > 
> > > From: Aizhamal Nurmamat kyzy 
> > > Sent: Wednesday, May 15, 2019 12:23:40 AM
> > > To: dev@community.apache.org
> > > Subject: Re: Roadshow Seattle
> > >
> > > I am based in Seattle, available for a chat over coffee, & would really
> > > love to have input here. Also know folks from Google and Lyft that
> would
> > > appreciate this kind of event in Seattle for sure.
> > >
> > > Please keep me in the loop.
> > >
> > > Thanks,
> > > Aizhamal
> > >
> > > *From: *Andrew Musselman 
> > > *Date: *Tue, May 14, 2019 at 3:23 PM
> > > *To: * 
> > >
> > > Aha great; yeah I'm in Seattle, looking forward to getting together.
> > > >
> > > > Best
> > > > Andrew
> > > >
> > > > On Tue, May 14, 2019 at 1:20 PM Kevin A. McGrail <
> kmcgr...@apache.org>
> > > > wrote:
> > > >
> > > > > Hah, I was just about to say ask Ross as step 1.
> > > > >
> > > > > On Tue, May 14, 2019, 15:08 Ross Gardler 
> > wrote:
> > > > >
> > > > > > Wearing my Microsoft hat, you have Microsoft engaged.
> > > > > >
> > > > > > Wearing my ASF hat I can help with reaching local companies. But
> > > before
> > > > > we
> > > > > > start reaching out let's decide what kind of event we want. I've
> > been
> > > > > > planning to do something for some time and would love to link up
> > with
> > > > you
> > > > > > on it. There is a good chance that you and I are thinking of
> > > different
> > > > > > events ;-)
> > > > > >
> > > > > > Are you local do Seattle? If so let's have a coffee (with anyone
> > > > > > available) figure out if we are sufficiently aligned and come
> back
> > > > with a
> > > > > > proposal.
> > > > > >
> > > > > > Ross
> > > > > >
> > > > > > Get Outlook for Android<
> > >
> >
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36&data=02%7C01%7C%7C434f5f305d024ec9a6ac08d6d9064cf7%7C84df9e7fe9f640afb435%7C1%7C0%7C636935018408634181&sdata=MPz%2BVlADYbtLm5Ghtzsmf%2FGzaWZAh5RuKbX3cTl34uk%3D&reserved=0
> > > >
> > > > > >
> > > > > > 
> > > > > > From: Andrew Musselman 
> > > > > > Sent: Tuesday, May 14, 2019 12:51:49 PM
> > > > > > To: dev@community.apache.org
> > > > > > Subject: Re: Roadshow Seattle
> > > > > >
> > > > > > Awesome, thanks for the feedback; I'll look at how to kick off
> > > > planning.
> > > > > > Any ideas for getting the word out and checking interest levels
> > > across
> > > > > > local companies/projects?
> > > > > >
> > > > > > On Tue, May 14, 2019 at 11:52 AM Kevin A. McGrail <
> > > kmcgr...@apache.org
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On 5/14/2019 2:30 PM, Aizhamal Nurmamat kyzy wrote:
> > > > > > > > I think Seattle would be a great place to host one. I’d be
> > there
> > > to
> > > > > > help
> > > > > > > if
> > > > > > > > it gets traction, Andrew.
> > > > > > >
> > > > > > > Same and I told him in person I would help.
> > > > > > >
> > > > > > > --
> > > > > > > Kevin A. McGrail
> > > > > > > Member, Apache Software Foundation
> > > > > > > Chair Emeritus Apache SpamAssassin Project
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fkmcgrail&data=02%7C01%7C%7C434f5f305d024ec9a6ac08d6d9064cf7%7C84df9e7fe9f640afb435%7C1%7C0%7C636935018408634181&sdata=wqB8m%2FP8cypAbO8gIe1psCI2LV2wRhLbG9yQZkQFsTo%3D&reserved=0
> > > > > > - 703.798.0171
> > > > > > >
> > > > > > >
> > > > > > >
> > > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


Re: Missing podling logos

2019-05-13 Thread Kenneth Knowles
+d...@datasketches.apache.org 

A logo was submitted alongside the SGA. Would using this logo be
acceptable? I don't have experience with this (just doc reading and my
working knowledge of ASF) since Beam was a merger that was extremely
distinct from its pre-Apache existence.

Kenn

*From: *Justin Mclean 
*Date: *Sat, May 11, 2019 at 9:47 PM
*To: * 
*Cc: * 

Hi,
>
> My second list for the logos  [1] had a few errors as it assumed .svg
> files existed for all projects. Try this one instead:
>
> Logos misisng:
> amaterasu
> annotator
> batchee
> brpc
> datasketches
> dlab
> flagon
> gobblin
> hudi
> iotdb
> marvin
> omid
> pinot
> ratis
> rya
> s2graph
> samoa
> sdap
> shardingsphere
> singa
> tamaya
> training
> tephra
> toree
> tuweni
> tvm
> weex
> zipkin
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/logos/
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


Re: [VOTE] ComDev supports formation of D&I committee

2019-05-10 Thread Kenneth Knowles
I cast a +1 (non-binding) and (* on D&I resolution) but I am not listed
below. Just for the record should someone navigate to this thread.

Kenn

*From: *Myrle Krantz 
*Date: *Thu, May 9, 2019 at 10:51 PM
*To: * 

The measure passes.  I will place the following text on the board agenda:
>
> "The ComDev PMC hereby requests that the board create a President's
> committee tasked with supporting our communities in their efforts to be
> diverse and welcoming places, and tasked with helping the ASF formulate a
> strategy to improve our diversity and inclusiveness.  The ComDev PMC
> likewise formally requests that the new committee look for ways in which
> ComDev can support our progress in these areas."
>
> The vote results are as follows:
>
> (The * indicate someone who is listed in the D&I proposal.)
> (The - indicate someone who made the caveat that the board should decide
> the committee form or someone who is ambivalent about committee form.)
>
> +1, Binding (8)
> Myrle Krantz *
> Shane Curcuru *
> Ross Gardler *
> Gris Cuevas *
> Bertrand Delacretaz *-
> Oliver Heintz
> Sharan Foga -
> Rich Bowen *-
>
> +1, Non-binding (8)
> Naomi Slater *
> Joan Touzet *
> Awasum Yannick
> Pierre Smits
> Jacques Le Roux
> Nate McCall
> Dinesh Joshi *
> Kevin McGrail *-
>
> -1, Non-binding (1)
> Tim Williams
>
> Other, Binding (2)
>
> Ulrich Stärk
> "+0.  not sure if a president's committee is the best way of getting this
> done or whether it would be
> better to have it as part of ComDev. But better do something than nothing
> at all. Plus, we can fix
> stuff later so I'll leave it to those wanting to drive it to figure it
> out."
>
> Jim Jagielski
> "I am +1 on the spin out; I am -1 on ComDev specifying a President's cmmt
> as the form of the spin out."
>
> For the record:
> Proposed text for the resolution was made available for discussion on April
> 30th here:
>
> https://lists.apache.org/thread.html/b985c0a7c00bf8bc7239721b233f3fc76e49a9e8e5809b8c02cd5f7d@%3Cdev.community.apache.org%3E
>
> Separate discussion of the committee form was started here on May 1st.  The
> last post on that thread also occurred on May 1st.
>
> https://lists.apache.org/thread.html/460bb18a855a1682a4ccab35b8c7d1a5bc9830ce394be28cb4f82de2@%3Cdev.community.apache.org%3E
> One person declined to participate, the rest seemed generally in favor of a
> president's committee.
>
> I explicitly stated that I would delay the vote on this measure until the
> discussion about committee form had completed, making it clear to the PMC
> that this vote was also about the form of the committee:
>
> https://lists.apache.org/thread.html/fecbfbd78dad49325ba036a9ea10d2fbf9bf804a6abce11c3054b7e0@%3Cprivate.community.apache.org%3E
>
> I started the vote on May 5th, 3 days after the discussion on committee
> form completed.  I'm closing it now on May 10th (5 days later).  There was
> wide ranging and extensive discussion in the month of April, and
> considerable time to participate in the more targeted discussion at the
> beginning of May.
>
> I am posting these results to both comdev and board, because the level of
> consensus w.r.t committee form has been a topic on board.
>
> Best Regards,
> Myrle
> PMC Member, Apache Community Development
>
> On Wed, May 8, 2019 at 6:40 PM Kevin A. McGrail 
> wrote:
>
> > I'm +1 [non-binding] for splitting D&I from ComDev off into it's own
> > committee/PMC/initiative/etc.  It hasn't been done well under comdev and
> > it's time to give it a shot on it's own.
> >
> > -KAM
> >
> > On 5/8/2019 10:48 AM, Myrle Krantz wrote:
> > > FYI all:
> > >
> > > I'm going to call the vote on Friday morning (CET).  If it passes, I'll
> > > also add it to the board agenda at that time.  I ask that everyone who
> > > wants to participate do so by then.
> > >
> > > Best Regards,
> > > Myrle
> > >
> > > On Wed, May 8, 2019 at 1:53 PM Tim Williams 
> > wrote:
> > >
> > >> -1...  it's completely unnecessary (as the work could easily be done
> > under
> > >> the CommDev banner) and gives the sense of "action" towards a cause
> > without
> > >> actually solving any real problem.  Ironically, I predict it will
> > fracture
> > >> the community and have the effect of removing diversity of views on
> this
> > >> very subject - creating an echo-chamber.  It'll pass though, so best
> > >> wishes...
> > >>
> > >> Thanks,
> > >> --tim
> > >>
> > >> On 2019/05/04 22:06:47, Myrle Krantz  wrote:
> > >>> I propose that ComDev submmit the following statement to the board:
> > >>>
> > >>> "The ComDev PMC hereby requests that the board create a President's
> > >>> committee tasked with supporting our communities in their efforts to
> be
> > >>> diverse and welcoming places, and tasked with helping the ASF
> > formulate a
> > >>> strategy to improve our diversity and inclusiveness.  The ComDev PMC
> > >>> likewise formally requests that the new committee look for ways in
> > which
> > >>> ComDev can support our progress in these areas."
> > >>>
> > >>> Here's my +1.
>

Re: [DISCUSSION] Documentation Hackathons at ApacheCon

2019-05-08 Thread Kenneth Knowles
+1 from me as well, and I'll be at ApacheCon NA to help out. Are there
steps to take now, like asking in the projects to see which of your ideas
fits best? I would guess the BoF+hackathon between all the projects from
GSoD would be cool. Worst case, you have too many people writing docs in a
room...

On Fri, May 3, 2019 at 1:40 PM Aizhamal Nurmamat kyzy
 wrote:

> I think this is a fantastic idea! I fully support any effort to foster
> documentation contributions/documentation improvements. Let me know if I
> can help in any way.
>
> Thanks,
> Aizhamal
>
> *From: *Sharan Foga 
> *Date: *Fri, May 3, 2019 at 1:30 PM
> *To: * 
>
> Hi All
> >
> > Recently with the Google Season of Docs, quite a few of our projects were
> > interested in applying to get some help with their documentation, so I’m
> > thinking, what if we try and add some sort of documentation section to
> our
> > ApacheCon hackathons.
> >
> > If we have enough people from a project community we could start at a
> very
> > basic level e.g writing up some install or very basic getting started
> docs.
> >
> > Another idea is that the projects who weren’t successful in getting a
> > technical writer with Season of Docs, bring their idea and have a
> hackathon
> > or Birds of a Feather session during ApacheCon to plan, prepare or write
> > something that could help.
> >
> > At one of the previous open source summits  I attended I saw a
> > presentation on what they called ‘Book Sprints’ where a group of people
> got
> > together for a fixed time period and then wrote the documentation and
> > pubished it.  While we may not have the same time frame, perhaps doing at
> > least a documentation proof of concept could be interesting for both Las
> > Vegas and Berlin.
> >
> > What do people think?
> >
> > Thanks
> > Sharan
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>


Re: [VOTE] ComDev supports formation of D&I committee

2019-05-06 Thread Kenneth Knowles
+1

On Mon, May 6, 2019 at 12:47 PM Sharan Foga  wrote:

> +1 on trying something new and separating this out. And as Bertrand
> mentions +1 for leaving it up to the Board to decide what type of committee
> structure they would like to see in place.
>
> Thanks
> Sharan
>
> On 2019/05/06 07:33:13, Bertrand Delacretaz 
> wrote:
> > On Sun, May 5, 2019 at 12:07 AM Myrle Krantz  wrote:
> > > ..."The ComDev PMC hereby requests that the board create a President's
> > > committee tasked with supporting our communities in their efforts to be
> > > diverse and welcoming places...
> >
> > +1, though I would leave it to the Board to decide which form of
> > committee is best.
> >
> > -Bertrand
> >
> > -
> > 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
>
>


Re: Request for Reviewers for Community Track at ApacheCon NA Las Vegas

2019-05-02 Thread Kenneth Knowles
I've requested reviewer status. There are multiple talks where I need to
recuse myself, but I wanted to make myself available as possible. I don't
really know the procedures at this point.

Kenn

On Thu, May 2, 2019 at 7:44 AM Piergiorgio Lucidi 
wrote:

> Hi,
>
> you can count on me!
>
> Cheers,
> PJ
>
> Il giorno mer 1 mag 2019 alle ore 22:16 Sharan Foga  ha
> scritto:
>
> > Hi All
> >
> > The CFP for ApacheCon NA, Las Vegas will be closing soon so I am looking
> > for some volunteers to help review and rate the Community track
> > submissions.
> >
> > If you are interested in helping out then please follow the submit a talk
> > link to login to the CFP system for ApacheCon NA, Las Vegas and then
> click
> > on the link to request to become a reviewer.
> >
> > https://asf.jamhosted.net/cfp.html
> >
> > Thanks
> > Sharan
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>
> --
> Piergiorgio
>


Re: Requesting the creation of a Diversity and Inclusion committee reporting to the President

2019-04-30 Thread Kenneth Knowles
> On Tue, Apr 30, 2019 at 12:44 PM Jim Jagielski  wrote:
> > ...ComDev, which has D&I in its charter and mandate...
>

Is this based on the charter of "The Community Development PMC is
responsible for helping people become involved with Apache projects" or is
there some more explicit resolution about comdev having D&I in its charter?

Kenn


Re: [Discuss] Attributing contributions to commercial vendors investing in projects

2019-04-21 Thread Kenneth Knowles
Thanks for this thread. I am learning a lot from these perspectives. At the
risk of adding noise, I'll share mine.

I first want to state my appreciation for how ASF governance works and how
it differs from other foundations. I did not really understand this when I
started and it is one of my favorite things I have learned these past few
years. Having recently reviewed other governance models including some of
those listed here, I would be much less interested in participating in that
form of project.

I would not like to attribute contributions to corporations, nor highlight
affiliations of listed contributors. Here's why:

 - Users and contributors already know who to contact to advance their
goals: dev@ and user@ lists. Encouraging backchannel to a corporation
rather than public discussion with the project is not good. We should do
the exact opposite: encourage companies to be transparent about their goals
in funding work on the project, for users and other contributors to give
feedback on.

 - Many of Beam's committers and PMC members have changed employment over
time. Beam has benefited from this IMO. Specifically because it was the
*individuals* who carried their knowledge, interests, & merit with them and
continued to contribute to Beam.

 - In Beam, we used to have on our website a table of PMC and committers,
with opt-in column for their employment. Due to the changes, this got out
of date quickly. When updating it, we ultimately decided to just link to
the ASF phonebook.

 - People read the table at a point in time and later remembered
out-of-date information, so even at an interpersonal level had the wrong
idea about other contributors context. So transparency actually led to
misinformation in practice. I'd love to be transparent without this
downside.

 - Employment and funding is not that simple! What about if some
contributions are by contractors paid by yet another company? (or yet
another layer of indirection!) Who are you going to thank? Laying out these
relationships (why? to allow users to try to backchannel influence?) is
complex and often confidential. Who is really driving the investment in
some area of a project? The one with the job/contract listing or the one
who chooses to pursue that job/contract?

And somewhat related to that last point, there's an angle to this that I
haven't heard here yet, that to me is absolute and transcends ASF's
policies: An employer tends to own copyright on their employees output by
default. That's enough. Are the regents of universities great researchers?
Do the owners of sports teams score points? Similarly, attributions for
contributions (code or not) of paid individuals still belongs to the
individuals. A company does not design systems, write code, have
conversations, give talks, write articles, etc. It cannot do any of these
things, because it is not a person. So, specifically "attributing
contributions to commercial vendors who support an Apache project" is
abhorrent to me, personally. If a project's site thanks a company for
paying people to work on the project, it isn't a direct affront to this,
but it is perilously close and has most of the same pragmatic downsides.

If an individual wants to thank their employer for paying them to work on a
project, that's their business. For the record, I'm *very* grateful for the
privilege to be paid to work on Apache projects; it is a defining aspect of
my career choices.

Seems like there are lots of possibilities other than a "thanks for paying
people to work on this" page. I'm curious to here direct thoughts on these:

 - A "powered by" page that lists interested vendors? (I noticed a lot of
these)
 - Joan's idea that companies could list individuals? (similar to the point
that if a company wants to advertise its relationship to a project, it has
the resources to do so)
 - A company could also not list individuals but just say "proud to support
XYZ open source project" and even write about how they use it and why they
pay people to contribute.

I'm not a proponent of any of these, in the abstract, but more curious what
others think.

Kenn

On Thu, Apr 18, 2019 at 8:06 AM Patricia Shanahan  wrote:

> On 4/17/2019 11:27 AM, Griselda Cuevas wrote:
>
> > It brings clarity to project roadmap and dependencies.
> > Knowing what companies are investing in a given area, allows users &
> > contributors know who to contact to move their own contributions
> faster and
> > gives companies the ability to accept user suggestions.
>
> Back when I was working in the computer industry, having to contact a
> competitor to expedite my ideas and to feed them suggestions would have
> been a very serious negative on contributing to a project.
>
> Even now, I would prefer my ideas to get full consideration by a
> project, without having to work through a third party.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For add

Fwd: Request for Interview Participants

2019-04-02 Thread Kenneth Knowles
I've seen a couple of threads about this sort of unsolicited email. Is
there an easy "what to do" doc my colleagues or I could follow? I am
especially perturbed because this went to u...@beam.apache.org.

Kenn

-- Forwarded message -
From: Amber Horvath 
Date: Sun, Mar 31, 2019 at 4:49 PM
Subject: Request for Interview Participants
To: 


To Whom it May Concern,

Hi, my name is Amber Horvath and I’m a first year graduate student in
Carnegie Mellon University’s Human Computer Interaction Institute. I’m
studying the perceived usability of Apache Beam as part of a larger study
of API usability. I’m interested in possibly recruiting some users of
Apache Beam through this mailing list to partake in an interview on your
usage of Apache Beam. The interview will cover questions relating to your
mental model of Apache Beam, how you have used Apache Beam, what
functionalities of the API you use most frequently and least frequently,
and how you integrate Apache Beam into your larger data stack. The
interview would be recorded and you would be compensated for $10 an hour,
with the interview not taking any longer than 2 hours.

Thank you for your time and please let me know if you are interested or
would like more information!

Amber Horvath


Re: on "meritocracy"

2019-03-29 Thread Kenneth Knowles
On Fri, Mar 29, 2019 at 9:52 PM Joan Touzet  wrote:

> "Wade Chandler"  wrote:
> > On one hand an organization “can” actively keep
> > people out based on personal attributes; intentional negative & bad;
> > don’t see this here; if you do, please give direct links; most will
> > certainly see that the same.
>
> > On another it “can” actively try to
> > attract more diversity; intentional positive; not sure I see this at
> > Apache.
>


> On another it “can” try to attract people who contribute,
> > and within that not have a bias related to any attribute of a person
> > other than they contribute; I see a lot of this at Apache; not bad
> > (evil), also good, not intentionally attracting diversity, but the
> > part that should be kept in mind is it is also good; not seeing this
> > as something to change as something that can be complemented.


Joan said so much, so much better than I could. But I want to emphasize
that this is a false trichotomy.

There are other ways that institutions reproduce their existing structure
and makeup. You may not find explicit discriminatory statements to call
out, especially not when those in power are self-aware. What you may find
is that there is systemic lenience applied to some candidates, for example
males (to the extent a PMC can discern), while stricter interpretations
applied to others. It is analogous to Joan's example of the value of
learning to listen and not speak in a meeting; quite hard to provide data
based on respectful silence. I am not an expert on the history of
discrimination but I expect this is boringly standard to any historian in
the area. I just wanted to mention one example of how it is not so simple.

An approach that seems promising (again - I'm not a historian or an
experienced activist) for counteracting the ease of disguising
discriminatory behavior is in your second paragraph - to explicitly
wholeheartedly embrace anti-discriminatory policies to welcome and protect
those less powerful / less favored. I think I will go watch Joan's
ApacheCon presentation for ideas. The only question in my mind is what an
effective implementation looks like..

Kenn


>
> Precisely the point. I'm in favour of this, though I know others are
> actively against it. I talked about this at length during my
> ApacheCon 2018 talk, proposing options that are well thought-out and
> fair, drawing from a wide variety of sources; I encourage you to
> listen to the full recording and read my slides before passing
> judgement.
>
> This effort can be engaged on a project-by-project basis, by the way.
> It doesn't need consent from people on this list.
>
>
> And it's obvious to me, at least, that just doing this has been
> insufficient. We need to cast our net wider. Rich said earlier in this
> thread:
>
> > Furthermore, EVERY SINGLE MONTH, there is at least one (and usually
> > several) response to a project report, encouraging them to more actively
> > pursue new committers, lower their bar to entry, actively mentor new
> > contributors, and so on.
>
> So yes, there is clearly a stated desire to improve, from the board
> level down.
>
> > Given you previously mentioned companies and performance reviews etc;
> > I will suggest part of the problem in those contexts are those
> > reviews are often measuring the wrong things, and not measuring the
> > drivers of the hierarchy of work in which most workers actually
> > exist within an organization; they please the street though.
>
> To me, this reads as you saying "We're promoting women and minorities
> just because they look good for our D&I numbers, not because they have
> the skillsets required." Was that what you really intended to say?
> If so that's borderline offensive, but as you say, irrelevant to
> our situation at Apache - so why bring it up? I'm trying to assume
> good faith on your part, but finding it hard to do so.
>
> > Were
> > they measuring the right things, and this odd dichotomy removed, and
> > the right signaling known to all, i.e. good communication of the
> > things that really matter, it would probably help a lot. I don’t
> > think this can be applied to Apache contributors though; it is
> > really clear the thing that matters; software that works and those
> > making that happen within a legal framework; very different than a
> > company and employee relationship and the motivators for it.
>
> On the contrary - we say "Community Over Code" is a core guiding
> principle of the ASF. So if that's the real thing that matters to us,
> and we state it loud and clear on our website, why aren't we deciding
> who gets "merit" based on that clearly and loudly, just as much as
> we care about code contributions?
>
> > Marginalized has a very specific and strong meaning; one of intent.
> > Do you intend to use it per that meaning?
>
> Not to speak for Naomi, but:
>
> It does not have that. Relegation to the margins may be transitive
> in nature, but it can be inadvertent. Learning to stop talking and
> let others who

Re: on "meritocracy"

2019-03-29 Thread Kenneth Knowles
I don't find this off-topic. I am grateful for this profile of Drupal,
which I otherwise would not have been exposed to. Thanks Justin!

I want to bring the main section headers and key items (curated by me) of
the Drupal article on list for ease of reading and archival. Apologies for
redundancy with the links that Justin shared.

1. Institute a community-wide code of conduct
a. With a working group to escalate to for mediation

2. Elevate a diverse group of leaders
a. have a D&I board to advance initiatives surrounding D&I
b. and a D&I contribution team to help underrepresented people
contribute to the Drupal codebase
c. address D&I in values: "We believe that the Drupal project benefits
from a diverse contribution pool, and we strive to foster a welcoming and
inclusive culture everywhere Drupal exists—at events, online, and in our
workplaces”

3. Make your project accessible to a diverse user base (hits home as I
think a lot about how they user base becomes the contributor base)

4. How private companies can promote open source diversity
a. for most engineers, open source work is a luxury, and one that is
not afforded to underrepresented people
b. companies—particularly ones that profit from open source
technology—can solve this problem by giving employees time to contribute to
the projects the company uses

It sounds like the work Gris has been doing is like the work of the Drupal
D&I board and also the Drupal D&I contribution team.

Kenn

On Fri, Mar 29, 2019 at 3:40 PM Justin Mclean 
wrote:

> Hi,
>
> Slightly off topic but relevant. One think we could do is look at other
> foundations and communities and see what they have done that has worked for
> them. I come across this interesting artifice this morning [1]. Note it
> includes the steps that community took to build a diverse community, I’d
> also note we’ve taken some of those steps (e.g. have a code of conduct) but
> perhaps shows where we could do more. They have set up a Drupal Diversity &
> Inclusion team [5] that spells out it values [2] and has  among other
> things guide on moderation, [3] and participation [4], Now the ASF is
> different to Drupal and some of those tings may not fit but it would be
> useful I think to at least consider them.
>
> Thanks,
> Justin
>
> 1.
> https://angel.co/blog/drupals-angela-byron-on-building-a-diverse-community
> 2.
> https://www.drupal.org/docs/8/modules/drupal-diversity-inclusion/statement-of-values
> 3.
> https://www.drupal.org/docs/8/modules/drupal-diversity-inclusion/drupal-diversity-inclusion-participation-moderation-1
> 4.
> https://www.drupal.org/docs/8/modules/drupal-diversity-inclusion/participation-moderation-guidelines/participant-guidelines
> 5. https://www.drupal.org/project/diversity
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


Re: Google Season of Docs 2019

2019-03-29 Thread Kenneth Knowles
Is this taken care of? Did ASF apply? Is there anything more that I could
help with at all? I would also be happy to review anything.

Kenn

On Fri, Mar 22, 2019 at 3:14 AM Sharan Foga  wrote:

> Hi Dinesh
>
> It's great to hear that the Apache Cassandra community is keen to be
> involved with this. I confirm that I will put an application on behalf of
> the ASF.
>
> Thanks
> Sharan
>
> On 2019/03/22 07:24:20, Dinesh Joshi 
> wrote:
> > Hi all,
> >
> > I am coordinating the GSoD effort in the Apache Cassandra community. We
> already have a few volunteers willing to help mentor the tech writer. Who
> can confirm whether ASF is applying as an organization? We will not apply
> separately.
> >
> > Thanks,
> >
> > Dinesh
> >
> > > On Mar 19, 2019, at 11:11 AM, Aizhamal Nurmamat kyzy
>  wrote:
> > >
> > > Hi Sharan,
> > >
> > > I'm happy to help with the ASF's application for SoD, if you need any
> > > support there.
> > >
> > > Thanks,
> > > Aizhamal
> > >
> > > On Mon, Mar 18, 2019 at 3:25 PM Sharan Foga  wrote:
> > >
> > >> Hi
> > >>
> > >> ComDev currently manages the ASF applications for GSoC so it might
> make
> > >> sense for us to centralise the application for this too.
> > >>
> > >> We would need 2 people to manage the ASF organisation application as a
> > >> mentor organisation as well as administer the projects and mentors.
> > >>
> > >> If selected then each project participating would need to guarantee at
> > >> least 2 mentors to work with the technical writer.  We currently
> collect
> > >> the GSoC ideas via a JIra so perhaps that could be adapted for GSoD
> too,
> > >>
> > >> The timeline is tight - I think 2nd April is when applications open.
> It
> > >> already sounds like the level of interest is high so we need to act
> quickly
> > >> if we want to participate.
> > >>
> > >> Thanks
> > >> Sharan
> > >>
> > >> On 2019/03/12 18:14:54, Dave Fisher  wrote:
> > >>> Hi -
> > >>>
> > >>> Looks pretty cool.
> > >>>
> > >>> Cc: to Apache Community Development.
> > >>>
> > >>> Regards,
> > >>> Dave
> > >>>
> > >>> Sent from my iPhone
> > >>>
> >  On Mar 12, 2019, at 9:22 AM, Huxing Zhang 
> wrote:
> > 
> >  Hi,
> > 
> >  Google Season of Docs 2019[1] seems to be an interesting project,
> >  which bring open source project and technical writer communities
> >  together, just Like Google summer of code.
> > 
> >  I think the Dubbo can benefit from the project, especially the
> English
> >  version of documentation could be improved.
> > 
> >  How do you think?
> > 
> >  [1] https://developers.google.com/season-of-docs/docs/timeline
> > 
> >  --
> >  Best Regards!
> >  Huxing
> > >>>
> > >>>
> > >>> -
> > >>> 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
> > >>
> > >>
> >
> >
> > -
> > 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
>
>


Re: on "meritocracy"

2019-03-29 Thread Kenneth Knowles
Sign me up as well. I assume there will be some announcement of the mailing
list or jira board here?

Interested in observing where ASF goes on the meritocracy thread,
interested in actively contributing where I can on diversity efforts.

Kenn

On Fri, Mar 29, 2019, 10:57 Bertrand Delacretaz 
wrote:

> Hi,
>
> On Fri, Mar 29, 2019 at 6:13 PM Joan Touzet  wrote:
> > ...I think Bertrand here has the
> > lead since he's working on the website refresh
>
> Not really, I helped update a small part of apache.org for the 20th
> anniversary but that's it.
>
> However, if we can come to a consensus about that needs to be modified
> on the website I'm happy to help make the actual changes.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


Re: on "meritocracy"

2019-03-21 Thread Kenneth Knowles
Thanks for these links to interesting reading. These are topics I care
deeply about. I'd be very interested in related analyses around specific
forms or instances of open source governance.

Kenn

On Thu, Mar 21, 2019 at 6:21 AM Rich Bowen  wrote:

> I read the article last week when it was doing the rounds, and I must
> admit I find it confusing. It appears to state that because we haven't
> yet achieved equity, we shouldn't bother striving for it. This seems
> false and harmful.
>
> I'm not aware of anybody (ok, fine, I am aware of one person) that
> thinks that Apache has arrived at meritocratic ideals. Rather, we strive
> towards them. If it's the *word* that's objectionable, sure, fine. But
> abandoning the *ideal* doesn't seem like a desired outcome.
>
> I acknowledge that I am the recipient of enormous luck and privilege. I
> certainly don't believe that I have arrived where I am in the world
> purely by hard work. And frankly, citing Stuart Varney as representative
> of ... well, anything or anyone, is, itself, kind of comic. He's a
> pompous blow-hard with a lengthy history of arrogant remarks about
> unsavory poor people who are not as wonderful as himself. I understand
> that these people exist, but citing them as representative seems weird.
>
> I would, however, ask what it is, specifically, that you're suggesting.
>
> On 3/20/19 5:49 AM, Naomi Slater wrote:
> > this article crossed my news feed today:
> >
> >
> https://www.fastcompany.com/40510522/meritocracy-doesnt-exist-and-believing-it-does-is-bad-for-you
> >
> > here's a key takeaway:
> >
> >> [...] in companies that explicitly held meritocracy as a core value,
> > managers assigned greater rewards to male employees over female employees
> > with identical performance evaluations. This preference disappeared where
> > meritocracy was not explicitly adopted as a value.
> >
> > many aspects of this piece mirror something I wrote for Model View
> Culture
> > a few years ago:
> > https://modelviewculture.com/pieces/the-open-source-identity-crisis
> >
> > namely, that "the meritocracy" is a status quo supporting, hierarchy
> > legitimizing myth used to justify people's existing social status and
> > treatment
> >
> > I'll say what I've said before: it's long since time for us to critically
> > examine the way we use the concept of "meritocracy" at Apache (this is
> > especially true in 2019 given what we know about the lack of diversity at
> > the ASF)
> >
> > when I was writing about this in 2014, I was already a few years behind
> the
> > curve re discourse about culture and tech diversity. it's now 2019 and
> even
> > FastCompany is writing about it
> >
>
> --
> 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
>
>


Re: Google Season of Docs 2019

2019-03-12 Thread Kenneth Knowles
That's a lot of dev lists on one thread. Adding a couple more... :-)

Kenn

On Tue, Mar 12, 2019 at 7:17 PM Dave Fisher  wrote:

>
>
> > On Mar 12, 2019, at 7:01 PM, Huxing Zhang  wrote:
> >
> > Hi Dave,
> >
> > On Wed, Mar 13, 2019 at 2:14 AM Dave Fisher 
> wrote:
> >>
> >> Hi -
> >>
> >> Looks pretty cool.
> >
> > Yes, all the ASF projects could benefit from it. I think ASF should
> > apply it on behalf of all ASF projects, just like how the GSoC work.
> > Am I right?
>
> Yes! And the time is pretty quick. I’m hoping a someone over here will
> volunteer to help.
>
> Regards,
> Dave
>
>
> >
> >>
> >> Cc: to Apache Community Development.
> >>
> >> Regards,
> >> Dave
> >>
> >> Sent from my iPhone
> >>
> >>> On Mar 12, 2019, at 9:22 AM, Huxing Zhang  wrote:
> >>>
> >>> Hi,
> >>>
> >>> Google Season of Docs 2019[1] seems to be an interesting project,
> >>> which bring open source project and technical writer communities
> >>> together, just Like Google summer of code.
> >>>
> >>> I think the Dubbo can benefit from the project, especially the English
> >>> version of documentation could be improved.
> >>>
> >>> How do you think?
> >>>
> >>> [1] https://developers.google.com/season-of-docs/docs/timeline
> >>>
> >>> --
> >>> Best Regards!
> >>> Huxing
> >>
> >
> >
> > --
> > Best Regards!
> > Huxing
> >
> > -
> > 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
>
>


Re: Beam's recent community development work

2019-02-22 Thread Kenneth Knowles
Done. And I did rephrase the bit about RTC to make it fit in better.

On Fri, Feb 22, 2019 at 4:51 AM Bertrand Delacretaz 
wrote:

> On Sun, Feb 10, 2019 at 10:54 PM Kenneth Knowles  wrote:
> > ...this is good to review or publish if you are
> > happy with it...
>
> sorry I missed that message, +1 to publishing!
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


Re: Beam's recent community development work

2019-02-21 Thread Kenneth Knowles
Re-reading the earlier feedback and starting point, it sounds like:

 - the post was generally approved of, assuming comments were addressed
 - there's not an established process for this sort of thing
 - the PMC agreed to give me authoring access

So I will suggest that lazy consensus is good here. I will wait a bit
longer, but would love to hit "publish" before the weekend.

Kenn


On Sun, Feb 10, 2019 at 1:54 PM Kenneth Knowles  wrote:

> I made a bunch of perturbations and undid them and eventually the links
> are working as-is... So anyhow this is good to review or publish if you are
> happy with it.
>
> Kenn
>
> On Sun, Feb 10, 2019 at 1:35 PM Kenneth Knowles  wrote:
>
>> Thanks for the feedback! I've revised to take it into account. I'll try
>> to reply inline to indicate how.
>>
>> On Mon, Jan 7, 2019 at 1:02 AM Bertrand Delacretaz <
>> bdelacre...@apache.org> wrote:
>>
>>> On Fri, Jan 4, 2019 at 10:35 PM Kenneth Knowles  wrote:
>>> > On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
>>> bdelacre...@apache.org>
>>> > wrote:
>>> > >... Feel free to draft your blog post and we can then review and
>>> publish!
>>> > I've drafted it
>>>
>>> Thank you, I reviewed [1] and it looks great to me!
>>>
>>> I have just 3 minor comments:
>>>
>>> -Add a link to the committer guidelines that you mention
>>>
>>
>> The first sentence of the paragraph on that was a link. Something about
>> my source is making most links not render. I got this one working, but many
>> others are not. I'll figure that out...
>>
>>
>>> -IIUC when you say "Every ~month" it means "about every month" - that
>>> was not obvious to me initially
>>>
>>
>> Changed to "about every month"
>>
>>
>>> -for RTC and CTR you might link to
>>> https://www.apache.org/foundation/glossary.html
>>
>>
>> Done (but link is not yet working per above)
>>
>>
>>>
>>> -Bertrand
>>
>>
>>
>>
>> On Mon, Jan 7, 2019 at 5:11 PM Craig Russell 
>> wrote:
>>
>>> I realize that this message might be hard to read since copy/paste
>>> formatting is gone. So here goes my attempt to clarify...
>>>
>>> On Jan 7, 2019, at 8:28 AM, Craig Russell  wrote:
>>>
>>> Hi Kenn,
>>>
>>> Thanks for contributing this. I think it's a nice introduction to Beam's
>>> community building efforts.
>>>
>>> Here are a couple of comments:
>>>
>>> > We want our contributor-base (hence committer-base) to be more spread
>>> across companies and backgrounds, for the usual Apache reasons.
>>>
>>> I'd elaborate instead of saying "for the usual Apache reasons". Which
>>> reasons are important to Beam?
>>>
>>
>> Done.
>>
>>
>>> > (we have committers from community development, tech writing,
>>> training, etc).
>>>
>>> I'd make this a sentence of its own.
>>>
>>
>> Agree. Done.
>>
>>
>>
>>> > you shouldn't be proposing a committer for other reasons,
>>>
>>> I don't understand "for other reasons".
>>>
>>> > Every ~month, we call for new discussions and revisit ~all prior
>>> discussions.
>>>
>>> I find the "~" to be distracting. Words please.
>>>
>>
>> Done.
>>
>> > For a potential committer, we did this:
>>>
>>> It's not clear to me when a person becomes a potential committer. Is it
>>> in the "repeat contributor" phase?
>>>
>>> > For an early contributor,
>>>
>>> Perhaps move this paragraph above the "For a potential committer"
>>> paragraph?
>>>
>>
>> Done. I think re-ordering and slight rephrase helped.
>>
>> > ~3~4 obvious committer candidates
>>
>>
>>> As above, remove "~".
>>>
>>
>> Done. "a few"
>>
>> > If we have no feedback about which guidelines were a concern, that is a
>>> red flag that we are being driven by bias.
>>>
>>> I don't understand this. Lack of concern might be considered a "good
>>> thing" not a red flag.
>>>
>>
>> Rephrased: "Formulating this feedback is important for helping
>> 

Re: Beam's recent community development work

2019-02-10 Thread Kenneth Knowles
I made a bunch of perturbations and undid them and eventually the links are
working as-is... So anyhow this is good to review or publish if you are
happy with it.

Kenn

On Sun, Feb 10, 2019 at 1:35 PM Kenneth Knowles  wrote:

> Thanks for the feedback! I've revised to take it into account. I'll try to
> reply inline to indicate how.
>
> On Mon, Jan 7, 2019 at 1:02 AM Bertrand Delacretaz 
> wrote:
>
>> On Fri, Jan 4, 2019 at 10:35 PM Kenneth Knowles  wrote:
>> > On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
>> bdelacre...@apache.org>
>> > wrote:
>> > >... Feel free to draft your blog post and we can then review and
>> publish!
>> > I've drafted it
>>
>> Thank you, I reviewed [1] and it looks great to me!
>>
>> I have just 3 minor comments:
>>
>> -Add a link to the committer guidelines that you mention
>>
>
> The first sentence of the paragraph on that was a link. Something about my
> source is making most links not render. I got this one working, but many
> others are not. I'll figure that out...
>
>
>> -IIUC when you say "Every ~month" it means "about every month" - that
>> was not obvious to me initially
>>
>
> Changed to "about every month"
>
>
>> -for RTC and CTR you might link to
>> https://www.apache.org/foundation/glossary.html
>
>
> Done (but link is not yet working per above)
>
>
>>
>> -Bertrand
>
>
>
>
> On Mon, Jan 7, 2019 at 5:11 PM Craig Russell  wrote:
>
>> I realize that this message might be hard to read since copy/paste
>> formatting is gone. So here goes my attempt to clarify...
>>
>> On Jan 7, 2019, at 8:28 AM, Craig Russell  wrote:
>>
>> Hi Kenn,
>>
>> Thanks for contributing this. I think it's a nice introduction to Beam's
>> community building efforts.
>>
>> Here are a couple of comments:
>>
>> > We want our contributor-base (hence committer-base) to be more spread
>> across companies and backgrounds, for the usual Apache reasons.
>>
>> I'd elaborate instead of saying "for the usual Apache reasons". Which
>> reasons are important to Beam?
>>
>
> Done.
>
>
>> > (we have committers from community development, tech writing, training,
>> etc).
>>
>> I'd make this a sentence of its own.
>>
>
> Agree. Done.
>
>
>
>> > you shouldn't be proposing a committer for other reasons,
>>
>> I don't understand "for other reasons".
>>
>> > Every ~month, we call for new discussions and revisit ~all prior
>> discussions.
>>
>> I find the "~" to be distracting. Words please.
>>
>
> Done.
>
> > For a potential committer, we did this:
>>
>> It's not clear to me when a person becomes a potential committer. Is it
>> in the "repeat contributor" phase?
>>
>> > For an early contributor,
>>
>> Perhaps move this paragraph above the "For a potential committer"
>> paragraph?
>>
>
> Done. I think re-ordering and slight rephrase helped.
>
> > ~3~4 obvious committer candidates
>
>
>> As above, remove "~".
>>
>
> Done. "a few"
>
> > If we have no feedback about which guidelines were a concern, that is a
>> red flag that we are being driven by bias.
>>
>> I don't understand this. Lack of concern might be considered a "good
>> thing" not a red flag.
>>
>
> Rephrased: "Formulating this feedback is important for helping
> contributors to learn, but it also serves as a check against bias and
> politics. If we found ourselves unable to specify such feedback, that is a
> sign that we are deciding for a reason other than those we have declared
> and agreed upon."
>
> > as RMS says
>>
>> Who/what <https://teams.googleplex.com/u/what> is RMS?
>>
>
> Rephrased and spelled out his name.
>
> I'll keep trying to figure out what is going on with the links, and if you
> know the answer please share it!
>
> Kenn
>
>
>>
>> Regards,
>>
>> Craig
>> >> On Jan 4, 2019, at 1:49 PM, Kenneth Knowles > k...@apache.org>> wrote:
>> >>
>> >> Here it is:
>> >>
>> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building
>> <
>> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-commu

Re: Beam's recent community development work

2019-02-10 Thread Kenneth Knowles
Thanks for the feedback! I've revised to take it into account. I'll try to
reply inline to indicate how.

On Mon, Jan 7, 2019 at 1:02 AM Bertrand Delacretaz 
wrote:

> On Fri, Jan 4, 2019 at 10:35 PM Kenneth Knowles  wrote:
> > On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
> bdelacre...@apache.org>
> > wrote:
> > >... Feel free to draft your blog post and we can then review and
> publish!
> > I've drafted it
>
> Thank you, I reviewed [1] and it looks great to me!
>
> I have just 3 minor comments:
>
> -Add a link to the committer guidelines that you mention
>

The first sentence of the paragraph on that was a link. Something about my
source is making most links not render. I got this one working, but many
others are not. I'll figure that out...


> -IIUC when you say "Every ~month" it means "about every month" - that
> was not obvious to me initially
>

Changed to "about every month"


> -for RTC and CTR you might link to
> https://www.apache.org/foundation/glossary.html


Done (but link is not yet working per above)


>
> -Bertrand




On Mon, Jan 7, 2019 at 5:11 PM Craig Russell  wrote:

> I realize that this message might be hard to read since copy/paste
> formatting is gone. So here goes my attempt to clarify...
>
> On Jan 7, 2019, at 8:28 AM, Craig Russell  wrote:
>
> Hi Kenn,
>
> Thanks for contributing this. I think it's a nice introduction to Beam's
> community building efforts.
>
> Here are a couple of comments:
>
> > We want our contributor-base (hence committer-base) to be more spread
> across companies and backgrounds, for the usual Apache reasons.
>
> I'd elaborate instead of saying "for the usual Apache reasons". Which
> reasons are important to Beam?
>

Done.


> > (we have committers from community development, tech writing, training,
> etc).
>
> I'd make this a sentence of its own.
>

Agree. Done.



> > you shouldn't be proposing a committer for other reasons,
>
> I don't understand "for other reasons".
>
> > Every ~month, we call for new discussions and revisit ~all prior
> discussions.
>
> I find the "~" to be distracting. Words please.
>

Done.

> For a potential committer, we did this:
>
> It's not clear to me when a person becomes a potential committer. Is it in
> the "repeat contributor" phase?
>
> > For an early contributor,
>
> Perhaps move this paragraph above the "For a potential committer"
> paragraph?
>

Done. I think re-ordering and slight rephrase helped.

> ~3~4 obvious committer candidates


> As above, remove "~".
>

Done. "a few"

> If we have no feedback about which guidelines were a concern, that is a
> red flag that we are being driven by bias.
>
> I don't understand this. Lack of concern might be considered a "good
> thing" not a red flag.
>

Rephrased: "Formulating this feedback is important for helping contributors
to learn, but it also serves as a check against bias and politics. If we
found ourselves unable to specify such feedback, that is a sign that we are
deciding for a reason other than those we have declared and agreed upon."

> as RMS says
>
> Who/what <https://teams.googleplex.com/u/what> is RMS?
>

Rephrased and spelled out his name.

I'll keep trying to figure out what is going on with the links, and if you
know the answer please share it!

Kenn


>
> Regards,
>
> Craig
> >> On Jan 4, 2019, at 1:49 PM, Kenneth Knowles  k...@apache.org>> wrote:
> >>
> >> Here it is:
> >>
> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building
> <
> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building
> >
> >>
> >> Kenn
> >>
> >> On Fri, Jan 4, 2019 at 1:44 PM Griselda Cuevas  >
> >> wrote:
> >>
> >>> Where could we find it?
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, 4 Jan 2019 at 13:35, Kenneth Knowles  wrote:
> >>>
> >>>> On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
> >>>> bdelacre...@apache.org>
> >>>> wrote:
> >>>>
> >>>>> Feel free to draft your blog post and we can then review and publish!
> >>>>>
> >>>>
> >>>> I've drafted it. It is pretty long but still feels terse to me.
> Feedback
> >>>> very welcome on that point. I will try to find time to give it another
> >>>> pass, unless someone tells me that it is fine as-is.
> >>>>
> >>>> Kenn
> >>>>
> >>>>
> >>>> -Bertrand
> >>>>>
> >>>>> -
> >>>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >>>>> For additional commands, e-mail: dev-h...@community.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >
> > Craig L Russell
> > Secretary, Apache Software Foundation
> > c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo <
> http://db.apache.org/jdo>
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo <
> http://db.apache.org/jdo>
>


Re: Beam's recent community development work

2019-01-04 Thread Kenneth Knowles
Here it is:
https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building

Kenn

On Fri, Jan 4, 2019 at 1:44 PM Griselda Cuevas 
wrote:

> Where could we find it?
>
>
>
>
> On Fri, 4 Jan 2019 at 13:35, Kenneth Knowles  wrote:
>
> > On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
> > bdelacre...@apache.org>
> > wrote:
> >
> > > Feel free to draft your blog post and we can then review and publish!
> > >
> >
> > I've drafted it. It is pretty long but still feels terse to me. Feedback
> > very welcome on that point. I will try to find time to give it another
> > pass, unless someone tells me that it is fine as-is.
> >
> > Kenn
> >
> >
> > -Bertrand
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > >
> > >
> >
>


Re: Beam's recent community development work

2019-01-04 Thread Kenneth Knowles
On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz 
wrote:

> Feel free to draft your blog post and we can then review and publish!
>

I've drafted it. It is pretty long but still feels terse to me. Feedback
very welcome on that point. I will try to find time to give it another
pass, unless someone tells me that it is fine as-is.

Kenn


-Bertrand
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


dev@community.apache.org

2018-12-19 Thread Kenneth Knowles
On Wed, Dec 19, 2018 at 8:19 PM Justin Mclean 
wrote:

>
> Slide 4
> - While the chair is responsible for making sure teh report is submitted
> to the board, it's the PMC who writes and contrite to it. "The report is
> technically single-author written by the PMC chair.” is sometimes teh case
> but in some project its more of a collaborative effort.
>

The phrasing at https://www.apache.org/foundation/board/reporting is "While
in most cases the chair works with other PMC members to write the report,
the report is ultimately the chair's responsibility to complete and submit."

I've been coached that the report is, ultimately:

 - from: the chair
 - to: the Board
 - about: Beam

In practice, it is collaboratively drafted on dev@beam. I think there's
subtlety here that I probably don't understand fully. Sort of like how the
PMC selects a chair but the board appoints the person.

Can you help me understand this better?

Kenn


Slide 9
> - Voting on contentious issues can cause division and split the community,
> so care needs to be taken to build consensus before a vote of this nature.
> - Voting on releases is different, -1 is not a veto
>
> Slide 10
> - CTR is much more common on ASF projects
>
> Slide 12
> - The tick and crosses are misleading, committer can be involved in
> everything but don’t have binding votes including on releases.
>
> Slide 15
> - Quick to review PRs need not apply with CTR and committer can mentor
> contributors as well in fact they may do that more than PMC members.
>
> I;’ll give some more feedback when I get a chance.
>
> Thanks,
> Justin
>
> 1. https://whimsy.apache.org/roster/
> 2. https://www.apache.org/foundation/policies/conduct.html
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


Re: Discussions in pull requests vs. dev list (was: The Apache Way and good developers...)

2018-11-02 Thread Kenneth Knowles
This comes up a lot on Beam too. We have a practice where if a PR is a big
change, or if discussion veers into into design details rather than just
code, we expect our committers to say "let's move this to the dev list". We
also try to encourage everyone to announce on dev@ not just for the design
discussion, but also to circle back and close the loop once it is merged.
Otherwise the archive is a bunch of loose ends and you can't tell what was
done.

It takes constant work to maintain this culture. We are not nearly 100%
successful; people are sometimes surprised at what has happened that they
didn't know about. Partly, it is just that there is so much going on (10-20
PRs a day) but I would eagerly follow progress and contribute (ideally,
availability pending) to any ideas for (opt-in) culture or automation work
on this topic.

Kenn

On Fri, Nov 2, 2018 at 11:02 AM Christopher  wrote:

> In Accumulo and Fluo, we route to notifications@ also. If these went
> to dev@, it would be too spammy, and I suspect even fewer people would
> participate on important dev@ threads than they do now. Letting it go
> to notifications@, people can subscribe to all activity there, if they
> wish... or they can go to GitHub and subscribe/unsubscribe to GitHub
> notifications for the entire repo ("Watch"), or per-thread, based on
> their individual desires. They can also unsubscribe from
> notifications@ to avoid duplicate notices if they are already
> subscribed to GitHub's notifications (which, to be honest, are far
> more useful, easier to read, and better formatted, than emails from
> ASF with the same content; you can also automatically avoid notices
> from your own activity... something you can't do on list). Using
> notifications@ instead of dev@ and users choosing (or not) to get
> notifications from GitHub is the best of both worlds and provides
> maximal user choice.
>
> There may be room for suggested improvements and best practices, but I
> think it would be a mistake if ASF were to try to impose a more spammy
> workflow to dev@ onto every PMC, as a requirement. I understand the
> utility and universality of mailing lists... but there comes a point
> where our reliance on them for all activity, becomes a deterrent to
> ASF participation, especially for younger contributors who expect more
> convenience than threaded walls of text in their email inbox.
> On Fri, Nov 2, 2018 at 1:46 PM Joan Touzet  wrote:
> >
> > We also use them successfully on CouchDB and I don't see the problem
> here.
> > We do route these notifications to notifications@, not dev@.
> > My email client properly threads multiple comments on the same PR.
> >
> > Another option is to use the GitHub "watch" functionality on a
> repository, which can provide better formatted emails than the ASF Infra
> solution currently does. They also seem to thread better for some.
> >
> > It's important to note that our process forces PRs for all changes to
> master or any release branch (R-T-C, not C-T-R), and that PRs cannot be
> merged unless our full test suite passes. This is automatically enforced by
> GitHub for us.
> >
> > Automating an email to dev@ with what PRs have opened/merged/closed
> with numerical counts sounds useful, but not mandatory. People that care
> can just use GitHub's "watch" function, then put filters in their mail
> client to highlight the things they care about (for instance, UI changes,
> or changes to a specific file or directory).
> >
> > -Joan
> > - Original Message -
> > From: "Christofer Dutz" 
> > To: dev@community.apache.org
> > Sent: Friday, November 2, 2018 1:30:47 PM
> > Subject: Re: Discussions in pull requests vs. dev list (was: The Apache
> Way and good developers...)
> >
> > Hi,
> >
> > Well in the PLC4X project we are using GitHub pull requests. All
> comments are forwarded to the list and this is fine. You are able to follow
> what's going on without much problems.
> >
> > However when it comes to the PR reviews, things tend to get it of hand.
> Every now and then I open my mail client to find 50 new emails and all of
> these are related to a single PR and each mail being a single comment. This
> is extremely annoying
> >
> > Chris
> >
> > Outlook for Android herunterladen
> >
> > From: Dave Fisher 
> > Sent: Friday, November 2, 2018 4:59:43 PM
> > To: dev@community.apache.org
> > Subject: Re: Discussions in pull requests vs. dev list (was: The Apache
> Way and good developers...)
> >
> > HI Bertrand,
> >
> > YES! This is the big issue with GitHub based projects/podlings.
> >
> > > On Nov 2, 2018, at 9:14 AM, Bertrand Delacretaz <
> bdelacre...@apache.org> wrote:
> > >
> > > Hi,
> > >
> > > I'd like to address this specifically as I think it's a common issue
> > > in many of our projects today.
> > >
> > > On Fri, Nov 2, 2018 at 4:31 PM Craig Russell 
> wrote:
> > >> ...One potential problem is the work flow using the github tools,
> which can have the effect
> > >> of dialog "off-list" be

Re: Beam's recent community development work

2018-10-31 Thread Kenneth Knowles
On Wed, Oct 31, 2018 at 8:04 AM Bertrand Delacretaz 
wrote:

> > On Thu, Oct 25, 2018 at 5:46 AM Kenneth Knowles  wrote:
> > > ...I would like to make this a more easy to link blog post. There was
> the
> > > comment "the dev@community.a.o team can give you access". Can this
> happen?...
>
> The PMC accepted doing so, I'm ready to give you authoring access for
> https://blogs.apache.org/comdev/
>
> However I don't see your Apache ID in the list of users there - could
> you try to login using the login link at https://blogs.apache.org/ ? I
> suppose this will cause your user to be added, as those blogs are
> linked with our LDAP services now.
>

I've done it. Seems to have worked as expected - after login with LDAP
credentials I was prompted to set up my blogging account (also `kenn`).

Kenn


> -Bertrand
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


Re: Beam's recent community development work

2018-10-24 Thread Kenneth Knowles
Hello!

(limiting prior thread to just comdev)

It has been quite some time, including a bit of parental leave for me, but
I would like to make this a more easy to link blog post. There was the
comment "the dev@community.a.o team can give you access". Can this happen?
What should I do? What are the next steps?

Kenn

On Sat, Jul 14, 2018 at 10:22 PM Kenneth Knowles  wrote:

>
> On Thu, Jul 12, 2018 at 1:43 AM Bertrand Delacretaz <
> bdelacre...@apache.org> wrote:
>
>> (note the mix of public and private lists)
>>
>> On Tue, Jul 10, 2018 at 9:56 PM Karl Fogel  wrote:
>> > ...Kenneth, are you planning to turn your email into a blog post or
>> > other easily-pointable-at-on-the-web thing?  I'm referring to your
>> original email.
>>
>> +1 for a blog post and you're welcome at
>> https://blogs.apache.org/comdev/ if desired, the dev@community.a.o
>> team can give you access.
>>
>
> Thanks for the encouragement. That sounds great. I am most comfortable
> providing a testimonial ("here's what seemed to work so far") rather than
> prescriptive advice, and mentioning the feedback appropriately.
>
> Kenn
>
>
>
>> -Bertrand
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>>
>>


Re: [DISCUSSION] Running another ASF Committer Diversity Survey

2018-10-01 Thread Kenneth Knowles
I would like to help in whatever way I can.

Kenn

On Mon, Oct 1, 2018 at 12:42 PM Jim Jagielski  wrote:

>
>
> > On Oct 1, 2018, at 1:28 PM, Nick Burch  wrote:
> >
> >
> > One suggestion I'd make is to review the text of some other foundations
> / tech organisation's surveys, and if we're missing questions they've asked
> or have different incompatible wording, make sure we have that for a
> reason. (Or update ours to match if no reason!). That would help us with
> comparing ourselves to other similar groups, and also would assist outside
> researchers trying to do meta-analysies too.
> >
>
> Agreed... as long as they really are peers. Otherwise, I think the results
> will skew things in a way which makes it difficult for us to have a clear
> and truthful insight on where we stand.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


Re: Beam's recent community development work

2018-07-14 Thread Kenneth Knowles
On Thu, Jul 12, 2018 at 1:43 AM Bertrand Delacretaz 
wrote:

> (note the mix of public and private lists)
>
> On Tue, Jul 10, 2018 at 9:56 PM Karl Fogel  wrote:
> > ...Kenneth, are you planning to turn your email into a blog post or
> > other easily-pointable-at-on-the-web thing?  I'm referring to your
> original email.
>
> +1 for a blog post and you're welcome at
> https://blogs.apache.org/comdev/ if desired, the dev@community.a.o
> team can give you access.
>

Thanks for the encouragement. That sounds great. I am most comfortable
providing a testimonial ("here's what seemed to work so far") rather than
prescriptive advice, and mentioning the feedback appropriately.

Kenn



> -Bertrand
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


Re: Beam's recent community development work

2018-07-02 Thread Kenneth Knowles
Thanks for the guidance Ted,

All of your points are well taken. I/we will definitely stay careful about
phrasing encouragement emails and our guidelines.

Kenn

On Sat, Jun 30, 2018 at 8:45 AM Ted Dunning  wrote:

>
> Ken,
>
> This is really good.
>
> I would like to emphasize one nuance, however. That is that when you get
> to the committer consideration step, there is a strong Apache tradition
> that the actual decision about committer-ship is not communicated to the
> candidate to avoid disappointment or campaigning during the vote.
>
> What you have could veer close to that, but I think that what you actually
> have in mind is just fine. I think that there could be a few tweaks to your
> process to emphasize how your efforts are OK.
>
> 1) when you contact a person and mention committer progress, please
> emphasize that it is a bit more like "your efforts have been noticed and
> appreciated. More of that sort of effort is something that often leads to
> becoming a committer. That actual process is confidential, however, so you
> won't know if or when it happens unless you get an invitation to become a
> committer"
>
> 2) the part about "do you want to become one, do you want feedback?" is
> golden just the way it is.
>
> 3) you mention "committer guidelines". This can be dangerous if it gets
> viewed as an application form or committer status checklist. This is a hard
> problem because it helps the PMC to have a list of things that are
> considered good qualities of a committer. I recommend keeping this danger
> in mind when composing emails to candidate committers. Above all else, try
> to avoid having the equivalent of an application form.
>
> Overall, I think that your results speak for themselves. Well done.
>
>
>
> On Fri, Jun 29, 2018 at 11:15 PM Kenneth Knowles  wrote:
>
>> Hi all,
>>
>> The ASF board suggested that we (Beam) share some of what we've been
>> doing for community development with dev@community.apache.org and
>> memb...@apache.org. So here is a long description. I have included
>> d...@beam.apache.org because it is the subject, really, and this is &
>> should be all public knowledge.
>>
>> We would love feedback! We based a lot of this on reading the community
>> project site, and probably could have learned even more with more study.
>>
>> # Background
>>
>> We face two problems in our contributor/committer-base:
>>
>> 1. Not enough committers to review all the code being contributed, in
>> part due to recent departure of a few committers
>> 2. We want our contributor-base (hence committer-base) to be more spread
>> across companies and backgrounds, for the usual Apache reasons. Our user
>> base is not active and varied enough to make this automatic. One solution
>> is to make the right software to get a varied user base, but that is a
>> different thread :-) so instead we have to work hard to build our community
>> around the software we have.
>>
>> # What we did
>>
>> ## Committer guidelines
>>
>> We published committer guidelines [1] for transparency and as an
>> invitation. We start by emphasizing that there are many kinds of
>> contributions, not just code (we have committers from community
>> development, tech writing, training, etc). Then we have three aspects:
>>
>> 1. ASF code of conduct
>> 2. ASF committer responsibilities
>> 3. Beam-specific committer responsibilities
>>
>> The best way to understand is to follow the link at the bottom of this
>> email. The important part is that you shouldn't be proposing a committer
>> for other reasons, and you shouldn't be blocking a committer for other
>> reasons.
>>
>> ## Instead of just "[DISCUSS] Potential committer XYZ" we discuss every
>> layer
>>
>> Gris (CC'd) outlined this: people go through these phases of relationship
>> with our project:
>>
>> 1. aware of it
>> 2. interested in it / checking it out
>> 3. using it for real
>> 4. first-time contributor
>> 5. repeat contributor
>> 6. committer
>> 7. PMC
>>
>> As soon as we notice someone, like a user asking really deep questions,
>> we invite discussion on private@ on how we can move them to the next
>> level of engagement.
>>
>> ## Monthly cadence
>>
>> Every ~month, we call for new discussions and revisit ~all prior
>> discussions. This way we do not forget to keep up this effort.
>>
>> ## Individual discussions
>>
>> For each person we have a separate thread on private@. This ensures we
&

Beam's recent community development work

2018-06-29 Thread Kenneth Knowles
Hi all,

The ASF board suggested that we (Beam) share some of what we've been doing
for community development with dev@community.apache.org and
memb...@apache.org. So here is a long description. I have included
d...@beam.apache.org because it is the subject, really, and this is & should
be all public knowledge.

We would love feedback! We based a lot of this on reading the community
project site, and probably could have learned even more with more study.

# Background

We face two problems in our contributor/committer-base:

1. Not enough committers to review all the code being contributed, in part
due to recent departure of a few committers
2. We want our contributor-base (hence committer-base) to be more spread
across companies and backgrounds, for the usual Apache reasons. Our user
base is not active and varied enough to make this automatic. One solution
is to make the right software to get a varied user base, but that is a
different thread :-) so instead we have to work hard to build our community
around the software we have.

# What we did

## Committer guidelines

We published committer guidelines [1] for transparency and as an
invitation. We start by emphasizing that there are many kinds of
contributions, not just code (we have committers from community
development, tech writing, training, etc). Then we have three aspects:

1. ASF code of conduct
2. ASF committer responsibilities
3. Beam-specific committer responsibilities

The best way to understand is to follow the link at the bottom of this
email. The important part is that you shouldn't be proposing a committer
for other reasons, and you shouldn't be blocking a committer for other
reasons.

## Instead of just "[DISCUSS] Potential committer XYZ" we discuss every
layer

Gris (CC'd) outlined this: people go through these phases of relationship
with our project:

1. aware of it
2. interested in it / checking it out
3. using it for real
4. first-time contributor
5. repeat contributor
6. committer
7. PMC

As soon as we notice someone, like a user asking really deep questions, we
invite discussion on private@ on how we can move them to the next level of
engagement.

## Monthly cadence

Every ~month, we call for new discussions and revisit ~all prior
discussions. This way we do not forget to keep up this effort.

## Individual discussions

For each person we have a separate thread on private@. This ensures we have
quality focused discussions that lead to feedback. In collective
discussions that we used to do, we often didn't really come up with
actionable feedback and ended up not even contacting potential committers
to encourage them. And consensus was much less clear.

## Feedback!

If someone is brought up for a discussion, that means they got enough
attention that we hope to engage them more. But unsolicited feedback is
never a good idea. For a potential committer, we did this:

1. Send an email saying something like "you were discussed as a potential
committer - do you want to become one? do you want feedback?"
2. If they say yes (so far everyone) we send a few bullet points from the
discussion and *most important* tie each bullet to the committer
guidelines. If we have no feedback about which guidelines were a concern,
that is a red flag that we are being driven by bias.

We saw a *very* significant increase in engagement from those we sent
feedback to, and the trend is that they almost all will become committers
over time.

## Results

 - Q1 we had no process and we added no new committers or PMC members.
 - Q2 when we tried these new things we added 7 committers and 1 PMC
member, with ~3~4 obvious committer candidates for next time around, plus
positive feedback from other contributors, spread across five companies.

We've had a pretty major uptick in building Beam as a result.

## Review-then-commit

We are dedicated to RTC as the best way to build software. Reviews not only
make the code better, but (with apologies to ASF/GNU differences) as RMS
says "The fundamental act of friendship among programmers is the sharing of
programs" and reviews are where we do that.

As a minor point, we also changed our "review-then-commit" policy to
require that *either* the reviewer or the author be a committer. Previously
the reviewer had to be a committer. Rationale: if we trust someone as a
committer, we should trust their choice of reviewer. This also helps the
community, as it engages non-committers as reviewers.



If you made it through this long email, thanks for reading!

Kenn

[1] https://beam.apache.org/contribute/become-a-committer/