Open Stack

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.

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

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

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

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

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

> 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.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-sigs/attachments/20170925/26747437/attachment-0001.sig>