On 12/19/18 12:41 AM, Aizhamal Nurmamat kyzy wrote:
Hello everyone!
My name is Aizhamal and I joined the Open Source Strategy team at Google
Cloud. I will work with Gris Cuevas (g...@apache.org) on two main projects:
-
New Contributor Experience - I’ll develop resources that will help
improve the onboarding experience of anyone who wants to contribute to an
Apache project for the first time
-
Open Source Documentation - I’ll develop resources related to best
practices for documentation in Open Source projects
Our team’s objective is to help new contributors become familiar with the
ASF, and help them be good citizens of the projects that they participate
in. With this we hope to support projects to develop a healthy Open Source
culture.
Our first contribution is this slide deck [1]
<https://s.apache.org/apache-way-for-everyone> with an introduction to The
Apache Way. We are aware it’s not the first presentation on this topic, but
we made it as a visual tool for presentation or self-study, so we’ve made
sure to have complete and detailed speaker notes for anyone to use.
If missed anything important, or misinterpreted some concept, I would
greatly appreciate your feedback.
Thanks so much for doing this, Aizhamal. This is great content,
really nicely presented with good speaker notes. I have a few
comments / suggestions for improvement. All are obviously just my
opinion and others may chime in with different views. As you know,
that's how it works...
I am referring to page numbers on the linked google doc as of today
(12/19). There may be a way to pull out a revision number, but I
don't know how to do that.
Page 6 - the term "peer-based" seems a little odd to me and it looks
like it is conflating two different things, both of which are
important to us: first - volunteers are *individuals* and second we
have a flat org structure. Related to the first is the idea of
project independence, which is also important (we can't have
projects dominated or controlled by external entities). Missing at
the top-level and usually included is *transparency* - everything
technical, everything required to follow what is happening to the
code is public and anyone interested needs to be able to follow what
is going on via public lists. This is covered more or less in the
notes end elsewhere, but I would personally elevate it to a basic
principle. Traditionally, we have talked about Community,
Meritocracy and Transparency as the pillars.
Page 7 - I don't like the term "toxic people." I would prefer
"toxic behaviors". I especially don't like the "toxic people ->
toxic communities". That makes it look like the right strategy is
to keep "toxic people" out. We are all toxic sometimes and we count
on each other to point the bad behaviors out and to demonstrate the
healthy ones.
Page 10- I disagree that RTC leads to "higher quality and
governance" and I am pretty sure that I am not alone in that view. I
especially disagree with the statement that RTC is "usually, the
recommended method." I would recommend dropping that slide
altogether or just stating that different communities, at different
times, use different ways to collaborate on code. The whole idea of
"code review" is actually kind of foreign to us. The whole point of
open development with good version control is so that code is
"reviewed" continuously and developed *collaboratively*. It is the
continuous review by a large community that delivers the quality in
ASF software.
Page 12 - I don't like the little check boxes limiting what
committers (or any community member, for that matter) are
responsible for. The only real difference between PMC members and
committers is that PMC members have binding votes on release and
committer votes. Committers absolutely do need to think about legal
/ IP and security issues. And they should be involved in mentoring
and encouraging contributors. And all community members should have
a voice in "rules and customs" for the project. PMC members are not
"managers" in the typical sense. They are ultimately accountable to
the Board and have binding votes, but they need to serve their
communities. And committers are not just coders.
Page 14 - I am not sure I agree with the last item. People leave
projects all the time and there is no expectation that they "explain
why they are leaving."
Page 15 - I don't think this is what you mean, but the slide makes
it looks like the primary responsibility of each group is the thing
on the right, which it isn't. I would also be careful with the
"don't be a bottleneck" idea. Committers (or PMC members) should
not feel like they have to quickly review all contributions. They
are volunteers. If PRs go for a long time without getting reviewed,
more volunteers may be needed or the community may simply not be
interested in them.
Thanks again for doing this, Aizhamal. My comments just suggest
some little patches. Great work!
Phil
In our plan, we also want to study how different projects implement The
Apache Way within their communities, e.g., cu
communication channels they use, PRs and code reviews, etc. We plan to
produce some material from that and share with the Apache community.
Thanks for your time, I am very excited to become part of this great
community!
Wishing you all wonderful holidays :)
Aizhamal
[1] https://s.apache.org/apache-way-for-everyone
On Fri, Nov 30, 2018 at 3:01 AM Michael Peoni <mapster1...@gmail.com> wrote:
Thank yoyu for the insight's i am currenty working on several projects
there is a couple with Google and Microsoft but keep getting blocked by
technical issues
On Thu, Nov 29, 2018 at 5:22 AM Bertrand Delacretaz <
bdelacre...@apache.org>
wrote:
On Thu, Nov 29, 2018 at 4:35 PM Santiago Gala <santiago.g...@gmail.com>
wrote:
...It is a long term process, and ideally quality increases
monotonically in
time, so you can stop or pause whenever you want or needs to,
always with positive results....
That's a great way to frame what I was trying to say!
We work like that in our software projects: do small things that add
value, so that if you leave or if for some reason the project's
resources diminish whatever you did was useful.
-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
