Open Stack

Excerpts from Jeremy Stanley's message of 2017-09-25 15:04:31 +0000:
> On 2017-09-25 21:51:34 +0800 (+0800), Zhipeng Huang wrote:
> > Disclaimer: The proposal comes from conclusions of offline
> > discussion in response to the padding thread in openstack-dev
> > mailing list.
> [...]
> 
> The subject of that thread was actually "Garbage patches for simple
> typo fixes," and stats padding was merely brought up as one of the
> possible motivations for such patches. Your use of the term
> "padding" throughout this proposal makes a presumption of the actual
> motivations of these contributors without citing research and
> supporting evidence. I recommend we find a more neutral term
> (perhaps "cosmetic," "trivial" or "superficial") which is general
> enough to cover the nature of the symptom without prematurely
> ascribing motive.

I like "cosmetic", although I don't think we need to include any of that
in the charter for the SIG. It's goals should revolve around outreach to
new and potential contributors, and the patch thing is just one small
part of that.

> 
> > we don't actually have a channel in a way that when a suspicious
> > padding activity is spotted, who should be the first contact to go
> > to.
> [...]
> 
> This again seems like jumping to a solution when the problem is not
> yet defined. The changes brought up in that thread as examples
> certainly seemed to miss the mark, but didn't strike me as
> "suspicious" so much as a silly and an indication those contributors
> lacked fundamental understanding of community norms.

Yeah, the idea here was to have an outlet so that existing contributors
who *are* upset by big batches of patches for some reason could ask
the SIG to look into them, instead of just being frustrated because
no one ever seems to do anything about the "problem". Further
characterization of the patches would be up to the SIG. Of course
project teams are free to review them, or not.

> 
> > Therefore we want to propose to establish the First Contact SIG to
> > solve the issue, institutionally and methodologically. (Hopefully
> > once for all in due time)
> 
> Here you also presume that we already know what the issue is, or
> even that there is just one specific issue to be solved. Further,
> whatever the issue(s) are, they are almost certain to be social in
> nature so are far more likely to involve ongoing engagement and
> maintenance rather than being something we can solve "once and for
> all."

I think what Zhipeng means here is that we would actually have some
folks in place to look into things. So instead of periodic email threads
on the dev list with suggestions for solutions, we would have people
actively working to implement them -- whatever they end up being.

> 
> > *Goals*:
> > 1. To serve as the first contact point when project develop team
> > finding something extraordinary.
> 
> This seems overly broad, and should probably more clearly define
> what sorts of incidents are on topic beyond "something
> extraordinary." As a reviewer I often find six extraordinary things
> before breakfast (that's sort of the point of code review), but most
> of them are unlikely to be relevant to this SIG.
> 
> > 2. To serve as the first contact point for local community to
> > reach out to the dev community, whether it is first-comer
> > onboarding, language translation issue, culture issue, etc.
> 
> This task could probably use a dedicated team/SIG on its own. I
> worry that the list of goals here is so broad and overreaching in
> scope as to be untenable.

This is the part I see as the most important. We spent a lot of
time in Denver talking about the new contributor portal, upstream
training, documentation, and all sorts of other things related to
bringing new people into the community. At times I was the only
intersection between the attendees, even though their work clearly
overlapped. I want those groups to start working together, and a SIG
seems like a good light-weight way to encourage that.

> 
> > 3. To enable groups like Upstream Institute to maximize their
> > capabilities on helping individuals, especially first-comers.
> 
> I'd want to know first what sort of help Upstream Institute needs
> without assuming we have solutions for them. Would it be better if
> the Upstream Institute volunteers instead simply joined as part of
> this SIG, if they have some particular needs they think it might be
> able to fulfil? And what other groups were you thinking of "like
> Upstream Institute," or was this merely forward-thinking in case
> some spring up?

Yes, we just want everyone interested in the topic to join.

> 
> > 4. To enable local chapters could get a direct line with the dev
> > community (not the foundation governance layer since we already
> > have many links on that level) without involvement of more
> > non-tech interest parties.
> 
> Maybe the point here is to bring together user groups and the
> developer community (because representatives of both would get
> involved in the SIG)? The way it's phrased sounds more like you want
> to create a new body separate from both user groups and project
> teams which acts as a go-between, which isn't really what a SIG is
> meant to be.

Other communities have a "welcome committee" or other similar body
that fields requests like "how can I start helping" and makes the
connection between the new person and the resources they need and
project teams. That could be one thing this SIG helps with, regardless
of whether the new members come with a local chapter or not.

> 
> > 5 To work with Linux Foundation CHAOSS program on project merit
> > identification.
> [...]
> 
> This could also probably be a separate group. Community health
> metrics and stats gathering are useful to devise strategies for
> engaging with new contributors, but the implementation/integration
> of the systems needed is nuanced and requires a much different
> skillset from interacting with people. Just getting CHAOSS to the
> point where it can successfully ingest and analyze activity unique
> to our community (which is fairly different from any of the LF
> projects) will be a lot of effort.

This may be a bit of a stretch goal. I would rather we start with some
of the other topics, first.

Doug