You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by Aizhamal Nurmamat kyzy <ai...@google.com.INVALID> on 2018/12/19 07:41:57 UTC
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Hello everyone!
My name is Aizhamal and I joined the Open Source Strategy team at Google
Cloud. I will work with Gris Cuevas (gris@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.
In our plan, we also want to study how different projects implement The
Apache Way within their communities, e.g., customs and etiquette,
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 <ma...@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 <
> bdelacretaz@apache.org>
> wrote:
>
> > On Thu, Nov 29, 2018 at 4:35 PM Santiago Gala <sa...@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-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
> >
>
--
*Aizhamal Nurmamat kyzy*
Open Source Program Manager
646-355-9740 Mobile
601 North 34th Street, Seattle, WA 98103
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Posted by "Kevin A. McGrail" <km...@apache.org>.
Hi Joana, nice to meet you!
One thought that comes to mind from your intro: On the events side, we
have 4 events in 2019. Are you able to help spread the word on those by
any chance using your social media channels?
Regards,
KAM
On 1/8/2019 5:18 PM, joanafilipa@google.com wrote:
>
> Hi everyone!
>
> My name is Joana Carrasqueira and I have just joined the Apache@Google team! I’ll be supporting Gris Cuevas with the organization of Open Source events and to help unifying the community.
>
> My main focus areas will be:
>
> - Events Management & Community Building to ensure that we can give back to the Foundation and the community, so other projects can use and benefit from the tools we produce.
>
> - Social media and communication strategy to bring our community close together, facilitate knowledge sharing and best practices.
>
> I look forward to collaborate with you all!
>
> All the best,
>
> Joana
>
> --
> Joana Carrasqueira
>
> Cloud Developer Relations Events Manager
>
> 415-602-2507 Mobile
>
> 1160 N Mathilda Ave, Sunnyvale, CA 94089
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
--
Kevin A. McGrail
VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Posted by jo...@google.com,
jo...@google.com.
On 2018/12/19 07:41:57, Aizhamal Nurmamat kyzy <ai...@google.com.INVALID> wrote:
> Hello everyone!
>
> My name is Aizhamal and I joined the Open Source Strategy team at Google
> Cloud. I will work with Gris Cuevas (gris@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.
>
> In our plan, we also want to study how different projects implement The
> Apache Way within their communities, e.g., customs and etiquette,
> 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 <ma...@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 <
> > bdelacretaz@apache.org>
> > wrote:
> >
> > > On Thu, Nov 29, 2018 at 4:35 PM Santiago Gala <sa...@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-unsubscribe@community.apache.org
> > > For additional commands, e-mail: dev-help@community.apache.org
> > >
> > >
> >
>
>
> --
>
> *Aizhamal Nurmamat kyzy*
>
> Open Source Program Manager
>
> 646-355-9740 Mobile
>
> 601 North 34th Street, Seattle, WA 98103
>
Hi everyone!
My name is Joana Carrasqueira and I have just joined the Apache@Google team! I’ll be supporting Gris Cuevas with the organization of Open Source events and to help unifying the community.
My main focus areas will be:
- Events Management & Community Building to ensure that we can give back to the Foundation and the community, so other projects can use and benefit from the tools we produce.
- Social media and communication strategy to bring our community close together, facilitate knowledge sharing and best practices.
I look forward to collaborate with you all!
All the best,
Joana
--
Joana Carrasqueira
Cloud Developer Relations Events Manager
415-602-2507 Mobile
1160 N Mathilda Ave, Sunnyvale, CA 94089
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The phrasing at https://www.apache.org/foundation/board/reporting <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.”
It also needs to reflect the view of the PMC. In one project I’m the chair of the PMC does all the work and I add anything they have missed or suggest a few changes, in another I generally write the whole thing with occasional input from other PMC members. Either is fine, but it makes the chair life a little easier if it done as a collaboration, and the chair may miss things. If the chair is not available for any reason a PMC member can submit the report.
Thanks,
Justin
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> The PMC doesn't select a chair (it doesn't have the authority), but it motions the board to appoint a specific person as chair, sort of like introducing legislation in a parliament but not being able to vote on it. The board then votes and either ratifies that motion, or it says "we're not going to do that and here's why". A chair is an officer of the foundation, and as such, HAS to be appointoed by the board of directors in the case of top level projects.
Which is what I said, but perhaps select is too strong a word, it’s more suggest. I’m not seen the board not accept a suggested chair for a project. I have however seen them remove chairs for one reason or another.
Thanks,
Justin
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
This summary may help [1] with a few things.
Thanks,
Justin
1. https://wiki.apache.org/incubator/DefaultProjectGuidelines
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Posted by Daniel Gruno <hu...@apache.org>.
On 12/20/18 3:14 AM, Kenneth Knowles wrote:
> On Wed, Dec 19, 2018 at 8:19 PM Justin Mclean <ju...@classsoftware.com>
> 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
>
The PMC doesn't select a chair (it doesn't have the authority), but it
motions the board to appoint a specific person as chair, sort of like
introducing legislation in a parliament but not being able to vote on
it. The board then votes and either ratifies that motion, or it says
"we're not going to do that and here's why". A chair is an officer of
the foundation, and as such, HAS to be appointed by the board of
directors in the case of top level projects.
The chair is basically a glorified secretary (with certain additional
day-to-day operational powers that I'll not go into detail about), and
while the report can be and often is made as a collaborative effort,
it's the chair responsibility to send that report - whether it be a team
effort or a single person writing it - to the board.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Posted by Kenneth Knowles <ke...@apache.org>.
On Wed, Dec 19, 2018 at 8:19 PM Justin Mclean <ju...@classsoftware.com>
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-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Also another missed point that in some projects (and more common in
incubating projects) is that committees = PMC
Thanks
Justin
On Thu., 20 Dec. 2018, 12:19 pm Justin Mclean <justin@classsoftware.com
wrote:
> HI,
>
> Nice presentation.
>
> Here my feedback on this some of this is more opinion (there’s many Apache
> ways) and some is just how things tends to be done in projects I’ve worked
> with.
>
> Slide 3:
> - We’re 6679 committers, 730 members, 199 top level PLCs, 52 podlings
> currently. [1] May be good to mention teh incubator and prodding projects.
>
> 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.
> - While only the board can appoint the chair, the chair is usually
> selected by the PMC.
>
> Slide 6
> - Rather than “Avoid toxic behaviours” I say “Discourage any toxic
> behaviour”
> - I’d be more explicit "Contributors represent themselves not the company
> they work for”
> - Code of conduct [2] should be mentioned here? in “Community > code”?
>
> Slide 7
> - include “merit doesn’t expire” concept here
> - I think the toxic stuff needs some work
>
> Slide 8
> - https://lists.apache.org is a better archive / search link
>
> 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
>
>
>
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
Nice presentation.
Here my feedback on this some of this is more opinion (there’s many Apache ways) and some is just how things tends to be done in projects I’ve worked with.
Slide 3:
- We’re 6679 committers, 730 members, 199 top level PLCs, 52 podlings currently. [1] May be good to mention teh incubator and prodding projects.
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.
- While only the board can appoint the chair, the chair is usually selected by the PMC.
Slide 6
- Rather than “Avoid toxic behaviours” I say “Discourage any toxic behaviour”
- I’d be more explicit "Contributors represent themselves not the company they work for”
- Code of conduct [2] should be mentioned here? in “Community > code”?
Slide 7
- include “merit doesn’t expire” concept here
- I think the toxic stuff needs some work
Slide 8
- https://lists.apache.org is a better archive / search link
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-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Posted by Aizhamal Nurmamat kyzy <ai...@google.com.INVALID>.
Thank you Phil for taking time to review the slides and providing such a
thorough feedback!
This is incredibly insightful -- I can definitely see the room for
improvement and clarifications. I will try and improve the slides and
speaker notes based on your feedback.
I have a few questions, which I've left inline:
On Wed, Dec 19, 2018 at 3:18 PM Phil Steitz <ph...@gmail.com> wrote:
> 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.
>
Ah thanks! This was the main struggle for me to put together, because I
couldn't come up with a clear list of basic principles. I found The Six
Principles[1] in the ASF website as core beliefs, but not much else was
written about them. Also, the same page refers to meritocracy as a basic
principle[2]. I think Community, Meritocracy and Transparency really
capture the philosophy of the Apache Way. I will change that slide to
include all these as top-level principles.
Perhaps I'll propose an update to the Philosophy section[1] of ASF website,
that presents these three as the basic principles to avoid confusion. Does
that sound fine to everyone?
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.
>
I think these are good points. The intention of this slide is not to
present it as a hard truth, but more as a general guideline, and especially
to highlight that the PMC is ultimately accountable to the Board if any
legal/governance issues arise, and they are in charge of discussing private
matters such as new committers, and critical security bugs.
To express that, I think it may be useful to replace the "X"-marks with
"maybe", and give a detailed explanation in the speaker notes. How does
this sound?
> 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."
>
This is true. I agree that explaining why is not necessary. My idea was to
encourage people to set appropriate expectations about their involvement.
Perhaps replace that with "Be considerate: Set appropriate expectations
about your involvement". How does that sound?
> 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.
>
That's a good point as well. I was trying to give some tips for
participating and contributing to a project in each role in a day-to-day
basis. I will rephrase the tips, and add some more detailed explanations in
the speaker notes.
Thanks a lot, I appreciate all the feedback! : )
-A
[1] https://www.apache.org/foundation/how-it-works.html#philosophy
[2] https://www.apache.org/foundation/how-it-works.html#meritocracy
--
*Aizhamal Nurmamat kyzy*
Open Source Program Manager
646-355-9740 Mobile
601 North 34th Street, Seattle, WA 98103
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Posted by Phil Steitz <ph...@gmail.com>.
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 (gris@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 <ma...@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 <
>> bdelacretaz@apache.org>
>> wrote:
>>
>>> On Thu, Nov 29, 2018 at 4:35 PM Santiago Gala <sa...@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-unsubscribe@community.apache.org
>>> For additional commands, e-mail: dev-help@community.apache.org
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Comments on the ppt deck - Onboarding Experience, Knowledge
Architecture, Events and D&I
Posted by Haoning Y Richter <ha...@gmail.com>.
Hi, Aizhamal,
Thank you for sharing such a nice presentation draft with us!
I love the neat design of the slides: simple, pleasant, and just-right
amount of colors.
My background is in the areas of strategic advisory, process design and
implementation, risk management, audit, finance, and accounting. I'm also
new to Apache.
If you don't mind, I'd like to offer some general suggestions for your
consideration from a new Apache member and non-technical perspectives.
*1. Slide # 1 - Cover Page Slide: *
"The Apache Way for Everyone". Would "The Apache Way" be more flexible
and more accurate? It reminds me of "HP Way" but HP did not say "HP Way
for Everyone".
I guess your presentation target audience will be the new Apache
contributors? In fact, your presentation could probably be a "recruiting"
or "introduction of Apache" tool for anyone who may consider joining Apache
in the future. If your presentation can be widely used beyond just the
newcomers, remove "for everyone" may be more appealing to the non-Apache
audience.
Currently, there is no "Table of Content". Would you consider adding it as
your new slide # 2?
*2. Slide # 2 "Mission of ASF": *
"...by providing services and support for *like-minded* software
projects..."
If this is indeed Apache mission or belief, I am curious about why
emphasize "like-minded"? I feel it might be helpful to provide some
context. I believe creativity and thinking outside of the box are the
critical mindset to technology in general. If everyone is thinking the
same or if we want everyone to conform, how effectively can we develop
better and new tools, applications, etc.?
*3. Slide # 3: *
This is the Overview slide. I recommend removing the last bullet point as
it doesn't provide much substance....and it appears self-promoting or
self-recognition without providing any achievement or evidence. If my
understanding of Apache is correct, it has become the most respected
technology community globally. Talented developers around the world take
the pride in contributing their own time and energy in developing Apache
projects and/or initiatives. Most of them (if not all) are not paid to do
so. With this said, I feel perhaps we can beef up this slide to add some
international facts so that the new members won't feel it is U.S. Centric
because it is not.
*4. Slide # 4 "Legal Structure of ASF": *
I'm not sure this slide shall be labeled as a legal structure. It appears
to be an organizational chart. or decision maker organization chart. What
kind of legal services or legal decisions will each of the roles play on
this slide?
*5. Slide # 5 "The Apache Way": *
This is an introduction slide. If "THe Apache Way" is driven by the "Six
Principles", then I'd suggest we move slide # 20 "The Six Principles" to be
slide # 6 to support slide # 5.
*6. Slide # 7 through Slide # 12: *
Those slides, in theory, shall be the explanatory slides to explain each of
the Six Principles.
*7. Slide # 8: *
"If it didn't happen on the mailing list, it didn't happen." I understand
the importance of putting everything (all communication) on emails.
However, it may not capture another or other expectations where perhaps
Apache organization has some form of record keeping methodology or
initiative where email correspondences are no longer the only way to keep
track of projects, comments, revisions, etc. Some people's contributions
may not be captured by sending to a mailing list due to various reasons.
From risk management perspectives, record retention is actually one of the
hot topics in protecting the company and minimizing legal exposure...
*8. Slide # 9: *
Assuming the sequence of the actions is correct, the numbering is a bit
confusing. Would you consider adding (or moving) the numbers to their
corresponding action?
Example: 1. Consensus 2. Preparing for a Vote . 3. Casting your Vote
4. Calling a Vote
Additionally, I feel we missed a step here. Conducting a Vote isn't the
objective. The objective is to get the votes in order to make a decision.
With this said, would you think perhaps we shall add the following two
steps after "4. Calling a Vote": 5. Consolidating Votes 6. Sharing and
Evaluating Votes 7. Making the Decision
*9. Slide # 12: *
"Responsibilities and Expectations". Given the volunteering nature of
Apache, it is very hard to hold each person accountable the same way as we
normally would do in a profit organization...Most volunteers have their
busy full-time jobs. Hence, sometimes, I can imagine some contributors may
wear different hats and some volunteers may not be able to commit to a
tight deadline given some circumstances. I would suggest not to put the
responsibilities in such a detailed way. Perhaps a more general conceptual
description of each role would be sufficient?
*10. Slide # 13 through Slide # 16: "Apache Citizenship for Everyone".*
I'd like to suggest we say "Apache Citizenship" (remove "for everyone")
No matter how good a process document is designed, communicated or
implemented, it won't matter unless the people will follow and execute. To
build a sustainable company or a community, the key is to establish a
healthy, safe, respectful, and empowering culture. People are the foremost
key to any success although having an effective process and documentation
are also important. With this said, I would highly recommend you to move
these slides to your earlier presentation. Perhaps right after the slide
of "Mission of Apache"?
*11. Slide # 17 and # 18: *
I think these two slides shall belong to slide # 19 "Graveyard Slides"
because they provide additional information (other resources)
Currently, there is only one slide # 20 under the "Graveyard Slides". As
mentioned above, the slide # 20 "The Six Apache Principles" is relevant and
a key slide, which probably drives most of the Apache projects and
initiatives. I think Slide # 20 shall be moved up to become slide # 6
(right after the current slide # 5).
In short, perhaps we can design this presentation deck with the following
structure:
1. Cover page
2. Table of Content
(1) Background (or History) Apache (accomplishments, awards,
recognition, etc.)
(2) Present Apache (# of projects, # of members, # of countries, etc.)
(3) Future Apache (Mission Statement, Goals/Objectives, etc.)
(4) Apache Culture (or Citizenship)
(5) Apache Six Principles
(6) Appendix (websites, books, articles, etc)
Thank you for your time spent in reviewing such a long email.
And thank you for putting together such a nice introduction deck, which I
have found it very informative and helpful as I'm new to Apache. I'm sure
this presentation will be appreciated by many future new members in the
years to come.
Happy Holidays to you and everyone on this mailing list!
Sincerely,
Haoning
(Haoning Richter)
Email: haoy96@gmail.com
On Tue, Dec 18, 2018 at 11:42 PM Aizhamal Nurmamat kyzy
<ai...@google.com.invalid> wrote:
> Hello everyone!
>
> My name is Aizhamal and I joined the Open Source Strategy team at Google
> Cloud. I will work with Gris Cuevas (gris@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.
>
> In our plan, we also want to study how different projects implement The
> Apache Way within their communities, e.g., customs and etiquette,
> 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 <ma...@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 <
> > bdelacretaz@apache.org>
> > wrote:
> >
> > > On Thu, Nov 29, 2018 at 4:35 PM Santiago Gala <santiago.gala@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-unsubscribe@community.apache.org
> > > For additional commands, e-mail: dev-help@community.apache.org
>
> --
>
> *Aizhamal Nurmamat kyzy*
>
> Open Source Program Manager
>
> 646-355-9740 Mobile
>
> 601 North 34th Street, Seattle, WA 98103
>
Re: Onboarding Experience, Knowledge Architecture, Events and D&I
Posted by "Kevin A. McGrail" <km...@apache.org>.
On 12/19/2018 2:41 AM, Aizhamal Nurmamat kyzy wrote:
> Our first contribution is this slide deck [1]
> <https://s.apache.org/apache-way-for-everyone> with an introduction to The
> Apache Way.
What an awesome job on it! Thanks Aizhamal.
--
Kevin A. McGrail
VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org