You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Joe Schaefer <jo...@yahoo.com> on 2013/06/16 16:16:48 UTC
[DISCUSS] PodlingBillOfRights
Since I realize that most of you can't be
bothered to look at the wiki page I created ;-),
I'll go ahead and post the current content
here for commentary. I hope the bulk of it
is non-controversial, though some of it may
not belong on the page...
------------------------------------------------
First a clarification- as provisional constructs of the Incubator PMC, podlings have no official standing in the corporation known as The Apache Software Foundation. So technically, it is a farce to claim that podlings have any formal rights whatsoever. What we write about here are promises and covenants the Incubator PMC will make a good-faith effort to honor.
1. First, podlings have a right to expect active participation and guidance from their mentors. That minimally includes participation in release votes, discussions and votes on new personnel, and signing off on a podling's quarterly reports.
2. Mentoring is done solely for the podling's benefit, and as such podlings have the right to fire mentors for any reason by a majority consensus vote on their private list. Just don't be denigrating about it, since mentors are always volunteers and not paid staff.
3. Podlings who find themselves in need of additional mentors have the right to ask general@incubator for more mentors to volunteer.
4. Podlings have the right to expect their quarterly reports to be read, reviewed, and critiqued by "shepherds" on the Incubator PMC, who are typically outside the podling's set of mentors.
5. Podlings have the right to express private concerns about anything related to their incubation to the Incubator Ombudsman <om...@incubator>, who will handle such communications as if they were sent anonymously.
6. Podlings have the right to express their opinions concerning their incubation efforts post-graduation (or post-mortem) in the form of an anonymous survey.
7. Podlings have the right to ignore commentary made on general@incubator in the middle of a VOTE thread, especially during releases. Reminder- release votes are a majority consensus vote, so seeing a few -1's occasionally is expected and often ignorable by the RM should they otherwise see a majority of at least 3 binding IPMC votes.
8. Podling committers have the right to remain unsubscribed to general@incubator. Any relevant policy/process changes will be passed along by the podling's mentors.
------------------------------------------------
Comments and critiques welcome. I'd like to
move the ball forward to a ceremonial endorsement
VOTE on this over the course of the remainder
of June, so please be constructive!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] PodlingBillOfRights
Posted by Upayavira <uv...@odoko.co.uk>.
FWIW, I read it, and liked it. I would support something like this in
terms of making it clearer what we are promising to podlings.
I guess a question that it would be worth clarifying - what happens to a
perfectly reasonable podling who's mentors resign/go awol, when the
Incubator PMC cannot recruit replacements? Can we make any promises at
that point?
Upayavira
On Sun, Jun 16, 2013, at 03:16 PM, Joe Schaefer wrote:
> Since I realize that most of you can't be
> bothered to look at the wiki page I created ;-),
> I'll go ahead and post the current content
> here for commentary. I hope the bulk of it
> is non-controversial, though some of it may
> not belong on the page...
>
>
> ------------------------------------------------
> First a clarification- as provisional constructs of the Incubator PMC,
> podlings have no official standing in the corporation known as The Apache
> Software Foundation. So technically, it is a farce to claim that podlings
> have any formal rights whatsoever. What we write about here are promises
> and covenants the Incubator PMC will make a good-faith effort to honor.
>
> 1. First, podlings have a right to expect active participation and guidance from their mentors. That minimally includes participation in release votes, discussions and votes on new personnel, and signing off on a podling's quarterly reports.
>
>
> 2. Mentoring is done solely for the podling's benefit, and as such podlings have the right to fire mentors for any reason by a majority consensus vote on their private list. Just don't be denigrating about it, since mentors are always volunteers and not paid staff.
>
>
> 3. Podlings who find themselves in need of additional mentors have the right to ask general@incubator for more mentors to volunteer.
>
>
> 4. Podlings have the right to expect their quarterly reports to be read, reviewed, and critiqued by "shepherds" on the Incubator PMC, who are typically outside the podling's set of mentors.
>
>
> 5. Podlings have the right to express private concerns about anything related to their incubation to the Incubator Ombudsman <om...@incubator>, who will handle such communications as if they were sent anonymously.
>
>
> 6. Podlings have the right to express their opinions concerning their incubation efforts post-graduation (or post-mortem) in the form of an anonymous survey.
>
>
> 7. Podlings have the right to ignore commentary made on general@incubator in the middle of a VOTE thread, especially during releases. Reminder- release votes are a majority consensus vote, so seeing a few -1's occasionally is expected and often ignorable by the RM should they otherwise see a majority of at least 3 binding IPMC votes.
>
>
> 8. Podling committers have the right to remain unsubscribed to general@incubator. Any relevant policy/process changes will be passed along by the podling's mentors.
> ------------------------------------------------
>
> Comments and critiques welcome. I'd like to
> move the ball forward to a ceremonial endorsement
> VOTE on this over the course of the remainder
> of June, so please be constructive!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] PodlingBillOfRights
Posted by Joe Schaefer <jo...@yahoo.com>.
>________________________________
> From: Roman Shaposhnik <rv...@apache.org>
>To: general@incubator.apache.org; Joe Schaefer <jo...@yahoo.com>
>Sent: Monday, June 17, 2013 3:26 PM
>Subject: Re: [DISCUSS] PodlingBillOfRights
>
>
>On Mon, Jun 17, 2013 at 11:48 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>>> So isn't learning this bit of information a crucial part of graduation?
>>> After
>>> all, once the project leaves the incubator its commiters and PMC won't have
>>> an access to the Ombudsman, isn't it in all of our best interest to teach
>>> them from the get-go what you've just described above?
>>
>>
>> Not really, because the type of information we're looking for is about the
>> IPMC, not the podling.
>
>Perhaps I misunderstood your idea with this new Ombudsman, but to me
>it sounded like you wanted, above all, a *safe* way for podling to complain.
>IOW, a kind of a way where their complaints will be heard yet their identity
>protected. If that's not your primary concern -- then I really feel like
>an Ombudsman represented yet another layer of bureaucracy and as
>such I'd be -0 on it.
Technically it's Alan's proposal not mine, but we're not all that different
in spirit. The "complaints" we are looking for are about the incubation
process, not about the podling's efforts at self-governance. It is important
to me that whomever is in the role of receiving such complaints not get
themselves in the middle of a project dispute- it's important for podlings
and full projects alike to deal with their own issues themselves through
the normal channels.
>
>> Isn't this an academic question? Those of us that have been here a while have
>> seen any number of cases where podling committers feel frustrated about the
>> process and powerless to do anything about it. This isn't a new problem.
>
>As you probably noticed, I've only started this discussion in the context
>of a PodlingBillOfRights. You did a great job of *reminding* podlings of
>their rights. Note, that just like in criminal law -- not reading somebody their
>Miranda rights doesn't mean they don't have them -- but reading them
>does make a huge difference. I think we can all agree that podlings already
>have those rights -- we are just making it really explicit.
>
>In that line of thought, what's not clear to me is what would be the
>difference if we changed your right #5 to:
>
>==========================================================================
>5. Podlings have the right to express private concerns about anything
>related to
>their incubation to their mentors and in private to the IPMC chair
>(email goes here).
>If they feel their concerns are still not being addressed they have a
>right to escalate
>to private@incubator.apache.org or all the way to the ASF board at
>board-private@apache.org
>This is the same right as given to all ASF project members.
>==========================================================================
That would be perfectly fine with me if the Ombudsman proposal does not meet
with the group's approval. I would in any case like to stabilize the document
with a proper email alias for the communications, so either ombudsman@incubator
or vp@incubator would be fine for that.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] PodlingBillOfRights
Posted by Roman Shaposhnik <rv...@apache.org>.
On Mon, Jun 17, 2013 at 11:48 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>> So isn't learning this bit of information a crucial part of graduation?
>> After
>> all, once the project leaves the incubator its commiters and PMC won't have
>> an access to the Ombudsman, isn't it in all of our best interest to teach
>> them from the get-go what you've just described above?
>
>
> Not really, because the type of information we're looking for is about the
> IPMC, not the podling.
Perhaps I misunderstood your idea with this new Ombudsman, but to me
it sounded like you wanted, above all, a *safe* way for podling to complain.
IOW, a kind of a way where their complaints will be heard yet their identity
protected. If that's not your primary concern -- then I really feel like
an Ombudsman represented yet another layer of bureaucracy and as
such I'd be -0 on it.
> Isn't this an academic question? Those of us that have been here a while have
> seen any number of cases where podling committers feel frustrated about the
> process and powerless to do anything about it. This isn't a new problem.
As you probably noticed, I've only started this discussion in the context
of a PodlingBillOfRights. You did a great job of *reminding* podlings of
their rights. Note, that just like in criminal law -- not reading somebody their
Miranda rights doesn't mean they don't have them -- but reading them
does make a huge difference. I think we can all agree that podlings already
have those rights -- we are just making it really explicit.
In that line of thought, what's not clear to me is what would be the
difference if we changed your right #5 to:
==========================================================================
5. Podlings have the right to express private concerns about anything
related to
their incubation to their mentors and in private to the IPMC chair
(email goes here).
If they feel their concerns are still not being addressed they have a
right to escalate
to private@incubator.apache.org or all the way to the ASF board at
board-private@apache.org
This is the same right as given to all ASF project members.
==========================================================================
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] PodlingBillOfRights
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: Roman Shaposhnik <rv...@apache.org>
> To: Joseph Schaefer <jo...@yahoo.com>
> Cc: general@incubator.apache.org
> Sent: Monday, June 17, 2013 2:02 AM
> Subject: Re: [DISCUSS] PodlingBillOfRights
>
> On Sun, Jun 16, 2013 at 10:48 PM, Joseph Schaefer
> <jo...@yahoo.com> wrote:
>> The typical escalation path is either board@ or board-private@ assuming
> private messages
>> to the chair are ineffective. Most of the time, for most of our projects,
> this has worked well enough.
>
> So isn't learning this bit of information a crucial part of graduation?
> After
> all, once the project leaves the incubator its commiters and PMC won't have
> an access to the Ombudsman, isn't it in all of our best interest to teach
> them from the get-go what you've just described above?
Not really, because the type of information we're looking for is about the
IPMC, not the podling.
>
> What's the danger of hooking up poddlings to the very channels they should
> be using once they graduate?
>
>> The real issue for the IPMC boils down to the judgement call of whether the
> standard
>> escalation procedures are working to everyone's satisfaction,
>
> Do we have real indication they are not?
Isn't this an academic question? Those of us that have been here a while have
seen any number of cases where podling committers feel frustrated about the
process and powerless to do anything about it. This isn't a new problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] PodlingBillOfRights
Posted by Roman Shaposhnik <rv...@apache.org>.
On Sun, Jun 16, 2013 at 10:48 PM, Joseph Schaefer
<jo...@yahoo.com> wrote:
> The typical escalation path is either board@ or board-private@ assuming private messages
> to the chair are ineffective. Most of the time, for most of our projects, this has worked well enough.
So isn't learning this bit of information a crucial part of graduation? After
all, once the project leaves the incubator its commiters and PMC won't have
an access to the Ombudsman, isn't it in all of our best interest to teach
them from the get-go what you've just described above?
What's the danger of hooking up poddlings to the very channels they should
be using once they graduate?
> The real issue for the IPMC boils down to the judgement call of whether the standard
> escalation procedures are working to everyone's satisfaction,
Do we have real indication they are not?
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] PodlingBillOfRights
Posted by Joseph Schaefer <jo...@yahoo.com>.
The typical escalation path is either board@ or board-private@ assuming private messages to the chair are ineffective. Most of the time, for most of our projects, this has worked well enough.
The real issue for the IPMC boils down to the judgement call of whether the standard escalation procedures are working to everyone's satisfaction, or are we now able to recognize a clear need for an independent, neutral contact point. All I can say is that I've seen this debated in the past while seemingly always failing to capture the core decision that really needs to be made. I trust this time round we'll stay focus on the practical issues and ignore our gut feelings about artificiality or other semantic concerns.
When you task someone to serve in this capacity, you don't necessarily wind up in a better place than when you started, because separating the wheat from the chaff in terms of new information gathered requires patience and skill. It's not easy to remain unbiased and objective and it can be emotionally draining and seemingly unrewarding, especially if it becomes a backdoor for leveling misconduct charges against each other.
But you have to have faith that there will be an upside to doing the outreach necessary to help us understand our true impact on these podlings. Reasonable people can disagree about the time and the place for an ombudsman, but I hope our willingness to grow and learn affords us some room for having some purposeful faith in where this could lead in our quest to do a better job at this. If this isn't the time or the place, what would be?
Sent from my iPhone
On Jun 17, 2013, at 1:16 AM, Roman Shaposhnik <rv...@apache.org> wrote:
> On Sun, Jun 16, 2013 at 7:16 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>> Since I realize that most of you can't be
>> bothered to look at the wiki page I created ;-),
>> I'll go ahead and post the current content
>> here for commentary. I hope the bulk of it
>> is non-controversial, though some of it may
>> not belong on the page...
>
> In general, I like it very much and I think it should
> be prominently displayed on Incubator web someplace.
>
> One comment thought:
>> 5. Podlings have the right to express private concerns about anything related
>> to their incubation to the Incubator Ombudsman <om...@incubator>,
>> who will handle such communications as if they were sent anonymously.
>
> For as long as there was a talk about Ombudsman the very
> idea of something like that in ASF has rubbed me the wrong
> way. The best way I can explain it is that it feels very artificial
> and asymmetric: suppose you are a committer on project "foo"
> and you feel like what's going on in the project is counterproductive
> to the ASF's charter. What's your recourse? Why isn't it the
> same for the poddling?
>
> Thanks,
> Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] PodlingBillOfRights
Posted by Roman Shaposhnik <rv...@apache.org>.
On Sun, Jun 16, 2013 at 7:16 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> Since I realize that most of you can't be
> bothered to look at the wiki page I created ;-),
> I'll go ahead and post the current content
> here for commentary. I hope the bulk of it
> is non-controversial, though some of it may
> not belong on the page...
In general, I like it very much and I think it should
be prominently displayed on Incubator web someplace.
One comment thought:
> 5. Podlings have the right to express private concerns about anything related
> to their incubation to the Incubator Ombudsman <om...@incubator>,
> who will handle such communications as if they were sent anonymously.
For as long as there was a talk about Ombudsman the very
idea of something like that in ASF has rubbed me the wrong
way. The best way I can explain it is that it feels very artificial
and asymmetric: suppose you are a committer on project "foo"
and you feel like what's going on in the project is counterproductive
to the ASF's charter. What's your recourse? Why isn't it the
same for the poddling?
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Instead of a Bill how about a Booklet? (was Re: [DISCUSS] PodlingBillOfRights)
Posted by Donald Whytock <dw...@apache.org>.
On Thu, Jun 20, 2013 at 12:22 PM, Alex Harui <ah...@adobe.com> wrote:
> 2) Apache has been around long enough and is large enough to have its own
> culture, with its own societal rules and tribal history. Lots of it is
> written down, but it is hard to find.
I never thought of that...Apache policy is the written equivalent of oral
history.
Don
Re: Instead of a Bill how about a Booklet? (was Re: [DISCUSS]
PodlingBillOfRights)
Posted by Chip Childers <ch...@sungard.com>.
On Thu, Jun 20, 2013 at 09:22:02AM -0700, Alex Harui wrote:
> Hi, As a newbie, I've generally quietly watched from the sidelines, but
> now I'm jumping in.
>
> +1 about "expectations" vs "rights". In fact, it occurred to me that a
> booklet or pamphlet more like the "What to expect whenŠ" book would be
> better. IMO, correctly set expectations make for happier people. Here is
> my draft of "What to expect when you enter the Apache Incubator".
This it a fantastic idea, and I feel like you have a *really* strong
start with your draft. Almost all of the issues that I (and others)
within CloudStack ran into were in your text... great distillation of
what to expect and how to deal with things!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Instead of a Bill how about a Booklet? (was Re: [DISCUSS]
PodlingBillOfRights)
Posted by Alex Harui <ah...@adobe.com>.
On 6/21/13 7:12 AM, "Chip Childers" <ch...@sungard.com> wrote:
>On Thu, Jun 20, 2013 at 08:22:00PM +0100, Upayavira wrote:
>> If, for whatever reason, they are unable or
>> unwilling to, you can ask on the incubator general list. If the optic is
>> too sensitive to discuss in public (eg a potential committer) you may
>> contact the incubator ombudsman at xxx@apache.org.
>
>Shouldn't this be private@incubator.apache.org *first*, and then the
>ombudsman only when it's a "complaint" that doesn't seem to be addressed
>through normal list discussions?
Even private@ could be readable by the person you are complaining about,
plus this assumes there will be an ombudsman, which isn't clear will be
the case.
I would say it this way:
11) Expect to be frustrated (or annoyed or even angered) at least once by
the failure of people to act as you justifiably think they should based on
whatever documents or emails you've read, or the role they claim
responsibility for, or even based on common sense. You might need one
more binding vote, or need consensus on what looks like a simple question
but ends up being debated for days when you need a ruling "yesterday". If
you choose to lodge a complaint against an individual, remember that every
mailing list is archived, some of them publicly, and the individual you
are complaining about may someday see what you have written. Before
complaining about an individual, find a mentor or ASF member and approach
them off-list, mainly as a sanity check to make sure your complaint is
justified in someone else's view, but also so that mentor or ASF member
can offer different ways to potentially resolve the problem. It is
generally wise not to name names in your early emails as you may not be
able to predict any existing relationship between the person you are
writing to and are writing about. A good way to choose an ASF member is
by getting a sense for who they are by their writings on general@incubator
or other ASF mailing lists. In other words, if you are new to the
neighborhood, it is prudent to be careful complaining about one of your
neighbors to the other neighbors until you understand the relationships
between them.
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Instead of a Bill how about a Booklet? (was Re: [DISCUSS]
PodlingBillOfRights)
Posted by Chip Childers <ch...@sungard.com>.
On Thu, Jun 20, 2013 at 08:22:00PM +0100, Upayavira wrote:
> If, for whatever reason, they are unable or
> unwilling to, you can ask on the incubator general list. If the optic is
> too sensitive to discuss in public (eg a potential committer) you may
> contact the incubator ombudsman at xxx@apache.org.
Shouldn't this be private@incubator.apache.org *first*, and then the
ombudsman only when it's a "complaint" that doesn't seem to be addressed
through normal list discussions?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Instead of a Bill how about a Booklet? (was Re: [DISCUSS]
PodlingBillOfRights)
Posted by Upayavira <uv...@odoko.co.uk>.
To distinguish between these two documents, they have different
flavours. One sets the expectations of podlings members, the other tells
mentors what is expected of them. This latter one should not be
forgotten. It is easy to sign up as a mentor, but not so easy to follow
through.
Having something you can be judged against is useful.
Upayavira
On Thu, Jun 20, 2013, at 10:37 PM, Rob Vesse wrote:
> I have written up the suggestions so far into a wiki page
>
> https://wiki.apache.org/incubator/WhatToExpect
>
> The content is pretty much what has been included in this thread
> reorganized with a few minor grammar tweaks here and there.
>
> If people like this notion feel free to edit the page or continue
> discussing here
>
> Rob
>
>
> On 6/20/13 12:22 PM, "Upayavira" <uv...@odoko.co.uk> wrote:
>
> >11. In certain circumstances, there are specific people charged with
> >certain responsibilities. Over time you can expect to learn who they
> >are, and where they hang out. Your mentor should be able to guide you
> >while you do learn. If, for whatever reason, they are unable or
> >unwilling to, you can ask on the incubator general list. If the optic is
> >too sensitive to discuss in public (eg a potential committer) you may
> >contact the incubator ombudsman at xxx@apache.org.
> >
> >Upayavira
> >
> >On Thu, Jun 20, 2013, at 05:40 PM, Rob Vesse wrote:
> >> +1
> >>
> >> Having also come to Apache by joining a now graduated podling (Apache
> >> Jena) I like the idea of a "What to expect" document and agree with
> >> pretty
> >> much everything that you lay out here. I think people outside of Apache
> >> often don't appreciate how a volunteer organization operates and many of
> >> your points describe this in terms new folks can understand, as you
> >> highlight Apache is not that different from many other organizations in
> >> many respects.
> >>
> >>
> >> I would suggest maybe adding a further point emphasizing the time aspect
> >> you raised in your previous email
> >>
> >> 4A) Don't forget that people here are geographically distributed and may
> >> be in very different timezones. There may be a significant lag between
> >> sending a communication and the intended recipient(s) even reading it,
> >> yet
> >> alone having the time to actually act upon it. A communication sent
> >> first
> >> thing in the morning in your timezone may arrive in the middle of the
> >> night for the recipient(s) so be prepared to wait for a response.
> >>
> >> I think those of us who work in the US or for multi-national companies
> >> get
> >> used to dealing with timezones and tend to forget that a lot of people
> >> come from countries where there is only one timezone.
> >>
> >> Rob
> >>
> >> On 6/20/13 9:22 AM, "Alex Harui" <ah...@adobe.com> wrote:
> >>
> >> >Hi, As a newbie, I've generally quietly watched from the sidelines,
> >>but
> >> >now I'm jumping in.
> >> >
> >> >+1 about "expectations" vs "rights". In fact, it occurred to me that a
> >> >booklet or pamphlet more like the "What to expect whenŠ" book would be
> >> >better. IMO, correctly set expectations make for happier people.
> >>Here is
> >> >my draft of "What to expect when you enter the Apache Incubator".
> >> >
> >> >1) Apache is staffed by volunteers, and a few paid, but overworked IT
> >> >folks known as Infra. As such, there is a very good chance that you
> >>will
> >> >get different answers from different respondents, and responses may be
> >> >delayed. This is not like your paid corporate job where there is
> >> >administration and infrastructure whose mind-share is fully dedicated
> >>to
> >> >serving you.
> >> >2) Apache has been around long enough and is large enough to have its
> >>own
> >> >culture, with its own societal rules and tribal history. Lots of it
> >>is
> >> >written down, but it is hard to find. Try to remember the last time
> >>you
> >> >started at a new company or team or club and how, even though there
> >>were
> >> >documents to read, there was always important stuff that you had to
> >>learn
> >> >some other way. Apache is no different, but with volunteers, even
> >>less is
> >> >written down, and people's recollections of history can vary widely and
> >> >nobody is paid to serve your needs except Infra which is overloaded.
> >> >3) Some folks are quiet, some are noisy, some complain, some are
> >> >optimistic. If you've worked on a large team, you've probably found
> >>this
> >> >to be true on that team as well. Success usually comes from finding
> >>out
> >> >which folks you deal with are of which personality type, and how best
> >>to
> >> >work with those people.
> >> >4) Often you just have to be patient. Pick your battles. Prioritize
> >>your
> >> >needs. Ask politely once for really important things, then plead
> >>again a
> >> >few days later.
> >> >5) Learn how to use an internet search engine. Try to find information
> >> >before you ask. The results may be hard to understand or confusing
> >>and be
> >> >careful about reading snippets without taking in some of the larger
> >> >context. But then your question will be better defined. Bonus if you
> >>can
> >> >quote a web page as part of your question.
> >> >6) Some folks want there to be a "bill of rights", but you don't have
> >>any
> >> >"rights" because there are no authority figures at Apache to enforce
> >>those
> >> >rights. Any "violations" have to be dealt with "socially". You can
> >>seek
> >> >help from the IPMC or even the board, but even they are volunteers and
> >> >will try to address the problem socially as well. You can expect and
> >> >demand respectful discourse, but sometimes tempers will boil over.
> >>That
> >> >happens in many workplaces, homes and other gatherings of people.
> >>Expect
> >> >it here as well, even more so sometimes, as there are relatively few
> >> >face-to-face encounters to encourage civility and limit chances of
> >> >mis-interpretation.
> >> >7) Your mentors may get too busy to follow the details of activity in
> >>your
> >> >podling. Use the [MENTOR] tag in the subject to try to catch their
> >> >attention. Escalate to the Incubator IPMC if they still don't have
> >>time
> >> >to respond.
> >> >8) Embrace diversity. Every podling is a little bit different and your
> >> >new podling may not exactly match up against existing documentation or
> >> >prior history. Ask for guidance, keep in mind that answers may vary,
> >>and
> >> >make your decision keeping these things in mind.
> >> >A) The primary goal is to cover your and Apache's butt legally. This
> >>may
> >> >require you to change build scripts and release packages in a way
> >>that is
> >> >painful for you and your customers.
> >> >B) Apache only officially releases source code. This may be a pain
> >>point
> >> >for any existing customers used to downloading binary packages.
> >> >C) At Apache, open source isn't just about making released source code
> >> >available. It is about trying to get the community involved early and
> >> >often before the source code is "release-ready".
> >> >9) Expect the unexpected. Sometimes, a document you find may be
> >> >out-of-date, and/or mention things that don't apply to you and when you
> >> >ask about it, you'll get a totally surprising answer.
> >> >10) Expect a ton of email. The temptation will be to unsubscribe from
> >> >some of the lists you are told to subscribe to, but it is important to
> >> >learn how to filter out stuff and skim other stuff as it helps you
> >>learn
> >> >about the people and personalities you will be dealing with
> >> >post-graduation on occasion, and if you end up on your project's PMC,
> >>you
> >> >will be responsible for mining important information from that email
> >> >stream.
> >> >
> >> >Now this may seem like it should make you run away screaming, but it
> >>all
> >> >adds up to one thing: This is the "cost" of getting a group of
> >>volunteers
> >> >to provide free software to a community of developers and users. You
> >>are
> >> >doing a good deed by coming to Apache. You could just go to GitHub,
> >>but
> >> >Apache provides some legal and logistical processes that should make
> >>your
> >> >customers feel more secure that the code you want to work on will be
> >> >available to the customer "forever" without fear that some individual
> >>can
> >> >disappear and sink the whole ship, or some legal issue will arise
> >>later.
> >> >
> >> >-Alex
> >> >
> >> >
> >> >
> >> >---------------------------------------------------------------------
> >> >To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> >For additional commands, e-mail: general-help@incubator.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Instead of a Bill how about a Booklet? (was Re: [DISCUSS]
PodlingBillOfRights)
Posted by Rob Vesse <rv...@yarcdata.com>.
I have written up the suggestions so far into a wiki page
https://wiki.apache.org/incubator/WhatToExpect
The content is pretty much what has been included in this thread
reorganized with a few minor grammar tweaks here and there.
If people like this notion feel free to edit the page or continue
discussing here
Rob
On 6/20/13 12:22 PM, "Upayavira" <uv...@odoko.co.uk> wrote:
>11. In certain circumstances, there are specific people charged with
>certain responsibilities. Over time you can expect to learn who they
>are, and where they hang out. Your mentor should be able to guide you
>while you do learn. If, for whatever reason, they are unable or
>unwilling to, you can ask on the incubator general list. If the optic is
>too sensitive to discuss in public (eg a potential committer) you may
>contact the incubator ombudsman at xxx@apache.org.
>
>Upayavira
>
>On Thu, Jun 20, 2013, at 05:40 PM, Rob Vesse wrote:
>> +1
>>
>> Having also come to Apache by joining a now graduated podling (Apache
>> Jena) I like the idea of a "What to expect" document and agree with
>> pretty
>> much everything that you lay out here. I think people outside of Apache
>> often don't appreciate how a volunteer organization operates and many of
>> your points describe this in terms new folks can understand, as you
>> highlight Apache is not that different from many other organizations in
>> many respects.
>>
>>
>> I would suggest maybe adding a further point emphasizing the time aspect
>> you raised in your previous email
>>
>> 4A) Don't forget that people here are geographically distributed and may
>> be in very different timezones. There may be a significant lag between
>> sending a communication and the intended recipient(s) even reading it,
>> yet
>> alone having the time to actually act upon it. A communication sent
>> first
>> thing in the morning in your timezone may arrive in the middle of the
>> night for the recipient(s) so be prepared to wait for a response.
>>
>> I think those of us who work in the US or for multi-national companies
>> get
>> used to dealing with timezones and tend to forget that a lot of people
>> come from countries where there is only one timezone.
>>
>> Rob
>>
>> On 6/20/13 9:22 AM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>> >Hi, As a newbie, I've generally quietly watched from the sidelines,
>>but
>> >now I'm jumping in.
>> >
>> >+1 about "expectations" vs "rights". In fact, it occurred to me that a
>> >booklet or pamphlet more like the "What to expect whenŠ" book would be
>> >better. IMO, correctly set expectations make for happier people.
>>Here is
>> >my draft of "What to expect when you enter the Apache Incubator".
>> >
>> >1) Apache is staffed by volunteers, and a few paid, but overworked IT
>> >folks known as Infra. As such, there is a very good chance that you
>>will
>> >get different answers from different respondents, and responses may be
>> >delayed. This is not like your paid corporate job where there is
>> >administration and infrastructure whose mind-share is fully dedicated
>>to
>> >serving you.
>> >2) Apache has been around long enough and is large enough to have its
>>own
>> >culture, with its own societal rules and tribal history. Lots of it
>>is
>> >written down, but it is hard to find. Try to remember the last time
>>you
>> >started at a new company or team or club and how, even though there
>>were
>> >documents to read, there was always important stuff that you had to
>>learn
>> >some other way. Apache is no different, but with volunteers, even
>>less is
>> >written down, and people's recollections of history can vary widely and
>> >nobody is paid to serve your needs except Infra which is overloaded.
>> >3) Some folks are quiet, some are noisy, some complain, some are
>> >optimistic. If you've worked on a large team, you've probably found
>>this
>> >to be true on that team as well. Success usually comes from finding
>>out
>> >which folks you deal with are of which personality type, and how best
>>to
>> >work with those people.
>> >4) Often you just have to be patient. Pick your battles. Prioritize
>>your
>> >needs. Ask politely once for really important things, then plead
>>again a
>> >few days later.
>> >5) Learn how to use an internet search engine. Try to find information
>> >before you ask. The results may be hard to understand or confusing
>>and be
>> >careful about reading snippets without taking in some of the larger
>> >context. But then your question will be better defined. Bonus if you
>>can
>> >quote a web page as part of your question.
>> >6) Some folks want there to be a "bill of rights", but you don't have
>>any
>> >"rights" because there are no authority figures at Apache to enforce
>>those
>> >rights. Any "violations" have to be dealt with "socially". You can
>>seek
>> >help from the IPMC or even the board, but even they are volunteers and
>> >will try to address the problem socially as well. You can expect and
>> >demand respectful discourse, but sometimes tempers will boil over.
>>That
>> >happens in many workplaces, homes and other gatherings of people.
>>Expect
>> >it here as well, even more so sometimes, as there are relatively few
>> >face-to-face encounters to encourage civility and limit chances of
>> >mis-interpretation.
>> >7) Your mentors may get too busy to follow the details of activity in
>>your
>> >podling. Use the [MENTOR] tag in the subject to try to catch their
>> >attention. Escalate to the Incubator IPMC if they still don't have
>>time
>> >to respond.
>> >8) Embrace diversity. Every podling is a little bit different and your
>> >new podling may not exactly match up against existing documentation or
>> >prior history. Ask for guidance, keep in mind that answers may vary,
>>and
>> >make your decision keeping these things in mind.
>> >A) The primary goal is to cover your and Apache's butt legally. This
>>may
>> >require you to change build scripts and release packages in a way
>>that is
>> >painful for you and your customers.
>> >B) Apache only officially releases source code. This may be a pain
>>point
>> >for any existing customers used to downloading binary packages.
>> >C) At Apache, open source isn't just about making released source code
>> >available. It is about trying to get the community involved early and
>> >often before the source code is "release-ready".
>> >9) Expect the unexpected. Sometimes, a document you find may be
>> >out-of-date, and/or mention things that don't apply to you and when you
>> >ask about it, you'll get a totally surprising answer.
>> >10) Expect a ton of email. The temptation will be to unsubscribe from
>> >some of the lists you are told to subscribe to, but it is important to
>> >learn how to filter out stuff and skim other stuff as it helps you
>>learn
>> >about the people and personalities you will be dealing with
>> >post-graduation on occasion, and if you end up on your project's PMC,
>>you
>> >will be responsible for mining important information from that email
>> >stream.
>> >
>> >Now this may seem like it should make you run away screaming, but it
>>all
>> >adds up to one thing: This is the "cost" of getting a group of
>>volunteers
>> >to provide free software to a community of developers and users. You
>>are
>> >doing a good deed by coming to Apache. You could just go to GitHub,
>>but
>> >Apache provides some legal and logistical processes that should make
>>your
>> >customers feel more secure that the code you want to work on will be
>> >available to the customer "forever" without fear that some individual
>>can
>> >disappear and sink the whole ship, or some legal issue will arise
>>later.
>> >
>> >-Alex
>> >
>> >
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> >For additional commands, e-mail: general-help@incubator.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Instead of a Bill how about a Booklet? (was Re: [DISCUSS]
PodlingBillOfRights)
Posted by Upayavira <uv...@odoko.co.uk>.
11. In certain circumstances, there are specific people charged with
certain responsibilities. Over time you can expect to learn who they
are, and where they hang out. Your mentor should be able to guide you
while you do learn. If, for whatever reason, they are unable or
unwilling to, you can ask on the incubator general list. If the optic is
too sensitive to discuss in public (eg a potential committer) you may
contact the incubator ombudsman at xxx@apache.org.
Upayavira
On Thu, Jun 20, 2013, at 05:40 PM, Rob Vesse wrote:
> +1
>
> Having also come to Apache by joining a now graduated podling (Apache
> Jena) I like the idea of a "What to expect" document and agree with
> pretty
> much everything that you lay out here. I think people outside of Apache
> often don't appreciate how a volunteer organization operates and many of
> your points describe this in terms new folks can understand, as you
> highlight Apache is not that different from many other organizations in
> many respects.
>
>
> I would suggest maybe adding a further point emphasizing the time aspect
> you raised in your previous email
>
> 4A) Don't forget that people here are geographically distributed and may
> be in very different timezones. There may be a significant lag between
> sending a communication and the intended recipient(s) even reading it,
> yet
> alone having the time to actually act upon it. A communication sent
> first
> thing in the morning in your timezone may arrive in the middle of the
> night for the recipient(s) so be prepared to wait for a response.
>
> I think those of us who work in the US or for multi-national companies
> get
> used to dealing with timezones and tend to forget that a lot of people
> come from countries where there is only one timezone.
>
> Rob
>
> On 6/20/13 9:22 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
> >Hi, As a newbie, I've generally quietly watched from the sidelines, but
> >now I'm jumping in.
> >
> >+1 about "expectations" vs "rights". In fact, it occurred to me that a
> >booklet or pamphlet more like the "What to expect whenŠ" book would be
> >better. IMO, correctly set expectations make for happier people. Here is
> >my draft of "What to expect when you enter the Apache Incubator".
> >
> >1) Apache is staffed by volunteers, and a few paid, but overworked IT
> >folks known as Infra. As such, there is a very good chance that you will
> >get different answers from different respondents, and responses may be
> >delayed. This is not like your paid corporate job where there is
> >administration and infrastructure whose mind-share is fully dedicated to
> >serving you.
> >2) Apache has been around long enough and is large enough to have its own
> >culture, with its own societal rules and tribal history. Lots of it is
> >written down, but it is hard to find. Try to remember the last time you
> >started at a new company or team or club and how, even though there were
> >documents to read, there was always important stuff that you had to learn
> >some other way. Apache is no different, but with volunteers, even less is
> >written down, and people's recollections of history can vary widely and
> >nobody is paid to serve your needs except Infra which is overloaded.
> >3) Some folks are quiet, some are noisy, some complain, some are
> >optimistic. If you've worked on a large team, you've probably found this
> >to be true on that team as well. Success usually comes from finding out
> >which folks you deal with are of which personality type, and how best to
> >work with those people.
> >4) Often you just have to be patient. Pick your battles. Prioritize your
> >needs. Ask politely once for really important things, then plead again a
> >few days later.
> >5) Learn how to use an internet search engine. Try to find information
> >before you ask. The results may be hard to understand or confusing and be
> >careful about reading snippets without taking in some of the larger
> >context. But then your question will be better defined. Bonus if you can
> >quote a web page as part of your question.
> >6) Some folks want there to be a "bill of rights", but you don't have any
> >"rights" because there are no authority figures at Apache to enforce those
> >rights. Any "violations" have to be dealt with "socially". You can seek
> >help from the IPMC or even the board, but even they are volunteers and
> >will try to address the problem socially as well. You can expect and
> >demand respectful discourse, but sometimes tempers will boil over. That
> >happens in many workplaces, homes and other gatherings of people. Expect
> >it here as well, even more so sometimes, as there are relatively few
> >face-to-face encounters to encourage civility and limit chances of
> >mis-interpretation.
> >7) Your mentors may get too busy to follow the details of activity in your
> >podling. Use the [MENTOR] tag in the subject to try to catch their
> >attention. Escalate to the Incubator IPMC if they still don't have time
> >to respond.
> >8) Embrace diversity. Every podling is a little bit different and your
> >new podling may not exactly match up against existing documentation or
> >prior history. Ask for guidance, keep in mind that answers may vary, and
> >make your decision keeping these things in mind.
> >A) The primary goal is to cover your and Apache's butt legally. This may
> >require you to change build scripts and release packages in a way that is
> >painful for you and your customers.
> >B) Apache only officially releases source code. This may be a pain point
> >for any existing customers used to downloading binary packages.
> >C) At Apache, open source isn't just about making released source code
> >available. It is about trying to get the community involved early and
> >often before the source code is "release-ready".
> >9) Expect the unexpected. Sometimes, a document you find may be
> >out-of-date, and/or mention things that don't apply to you and when you
> >ask about it, you'll get a totally surprising answer.
> >10) Expect a ton of email. The temptation will be to unsubscribe from
> >some of the lists you are told to subscribe to, but it is important to
> >learn how to filter out stuff and skim other stuff as it helps you learn
> >about the people and personalities you will be dealing with
> >post-graduation on occasion, and if you end up on your project's PMC, you
> >will be responsible for mining important information from that email
> >stream.
> >
> >Now this may seem like it should make you run away screaming, but it all
> >adds up to one thing: This is the "cost" of getting a group of volunteers
> >to provide free software to a community of developers and users. You are
> >doing a good deed by coming to Apache. You could just go to GitHub, but
> >Apache provides some legal and logistical processes that should make your
> >customers feel more secure that the code you want to work on will be
> >available to the customer "forever" without fear that some individual can
> >disappear and sink the whole ship, or some legal issue will arise later.
> >
> >-Alex
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Instead of a Bill how about a Booklet? (was Re: [DISCUSS]
PodlingBillOfRights)
Posted by Rob Vesse <rv...@yarcdata.com>.
+1
Having also come to Apache by joining a now graduated podling (Apache
Jena) I like the idea of a "What to expect" document and agree with pretty
much everything that you lay out here. I think people outside of Apache
often don't appreciate how a volunteer organization operates and many of
your points describe this in terms new folks can understand, as you
highlight Apache is not that different from many other organizations in
many respects.
I would suggest maybe adding a further point emphasizing the time aspect
you raised in your previous email
4A) Don't forget that people here are geographically distributed and may
be in very different timezones. There may be a significant lag between
sending a communication and the intended recipient(s) even reading it, yet
alone having the time to actually act upon it. A communication sent first
thing in the morning in your timezone may arrive in the middle of the
night for the recipient(s) so be prepared to wait for a response.
I think those of us who work in the US or for multi-national companies get
used to dealing with timezones and tend to forget that a lot of people
come from countries where there is only one timezone.
Rob
On 6/20/13 9:22 AM, "Alex Harui" <ah...@adobe.com> wrote:
>Hi, As a newbie, I've generally quietly watched from the sidelines, but
>now I'm jumping in.
>
>+1 about "expectations" vs "rights". In fact, it occurred to me that a
>booklet or pamphlet more like the "What to expect whenŠ" book would be
>better. IMO, correctly set expectations make for happier people. Here is
>my draft of "What to expect when you enter the Apache Incubator".
>
>1) Apache is staffed by volunteers, and a few paid, but overworked IT
>folks known as Infra. As such, there is a very good chance that you will
>get different answers from different respondents, and responses may be
>delayed. This is not like your paid corporate job where there is
>administration and infrastructure whose mind-share is fully dedicated to
>serving you.
>2) Apache has been around long enough and is large enough to have its own
>culture, with its own societal rules and tribal history. Lots of it is
>written down, but it is hard to find. Try to remember the last time you
>started at a new company or team or club and how, even though there were
>documents to read, there was always important stuff that you had to learn
>some other way. Apache is no different, but with volunteers, even less is
>written down, and people's recollections of history can vary widely and
>nobody is paid to serve your needs except Infra which is overloaded.
>3) Some folks are quiet, some are noisy, some complain, some are
>optimistic. If you've worked on a large team, you've probably found this
>to be true on that team as well. Success usually comes from finding out
>which folks you deal with are of which personality type, and how best to
>work with those people.
>4) Often you just have to be patient. Pick your battles. Prioritize your
>needs. Ask politely once for really important things, then plead again a
>few days later.
>5) Learn how to use an internet search engine. Try to find information
>before you ask. The results may be hard to understand or confusing and be
>careful about reading snippets without taking in some of the larger
>context. But then your question will be better defined. Bonus if you can
>quote a web page as part of your question.
>6) Some folks want there to be a "bill of rights", but you don't have any
>"rights" because there are no authority figures at Apache to enforce those
>rights. Any "violations" have to be dealt with "socially". You can seek
>help from the IPMC or even the board, but even they are volunteers and
>will try to address the problem socially as well. You can expect and
>demand respectful discourse, but sometimes tempers will boil over. That
>happens in many workplaces, homes and other gatherings of people. Expect
>it here as well, even more so sometimes, as there are relatively few
>face-to-face encounters to encourage civility and limit chances of
>mis-interpretation.
>7) Your mentors may get too busy to follow the details of activity in your
>podling. Use the [MENTOR] tag in the subject to try to catch their
>attention. Escalate to the Incubator IPMC if they still don't have time
>to respond.
>8) Embrace diversity. Every podling is a little bit different and your
>new podling may not exactly match up against existing documentation or
>prior history. Ask for guidance, keep in mind that answers may vary, and
>make your decision keeping these things in mind.
>A) The primary goal is to cover your and Apache's butt legally. This may
>require you to change build scripts and release packages in a way that is
>painful for you and your customers.
>B) Apache only officially releases source code. This may be a pain point
>for any existing customers used to downloading binary packages.
>C) At Apache, open source isn't just about making released source code
>available. It is about trying to get the community involved early and
>often before the source code is "release-ready".
>9) Expect the unexpected. Sometimes, a document you find may be
>out-of-date, and/or mention things that don't apply to you and when you
>ask about it, you'll get a totally surprising answer.
>10) Expect a ton of email. The temptation will be to unsubscribe from
>some of the lists you are told to subscribe to, but it is important to
>learn how to filter out stuff and skim other stuff as it helps you learn
>about the people and personalities you will be dealing with
>post-graduation on occasion, and if you end up on your project's PMC, you
>will be responsible for mining important information from that email
>stream.
>
>Now this may seem like it should make you run away screaming, but it all
>adds up to one thing: This is the "cost" of getting a group of volunteers
>to provide free software to a community of developers and users. You are
>doing a good deed by coming to Apache. You could just go to GitHub, but
>Apache provides some legal and logistical processes that should make your
>customers feel more secure that the code you want to work on will be
>available to the customer "forever" without fear that some individual can
>disappear and sink the whole ship, or some legal issue will arise later.
>
>-Alex
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Instead of a Bill how about a Booklet? (was Re: [DISCUSS]
PodlingBillOfRights)
Posted by Alex Harui <ah...@adobe.com>.
Hi, As a newbie, I've generally quietly watched from the sidelines, but
now I'm jumping in.
+1 about "expectations" vs "rights". In fact, it occurred to me that a
booklet or pamphlet more like the "What to expect whenŠ" book would be
better. IMO, correctly set expectations make for happier people. Here is
my draft of "What to expect when you enter the Apache Incubator".
1) Apache is staffed by volunteers, and a few paid, but overworked IT
folks known as Infra. As such, there is a very good chance that you will
get different answers from different respondents, and responses may be
delayed. This is not like your paid corporate job where there is
administration and infrastructure whose mind-share is fully dedicated to
serving you.
2) Apache has been around long enough and is large enough to have its own
culture, with its own societal rules and tribal history. Lots of it is
written down, but it is hard to find. Try to remember the last time you
started at a new company or team or club and how, even though there were
documents to read, there was always important stuff that you had to learn
some other way. Apache is no different, but with volunteers, even less is
written down, and people's recollections of history can vary widely and
nobody is paid to serve your needs except Infra which is overloaded.
3) Some folks are quiet, some are noisy, some complain, some are
optimistic. If you've worked on a large team, you've probably found this
to be true on that team as well. Success usually comes from finding out
which folks you deal with are of which personality type, and how best to
work with those people.
4) Often you just have to be patient. Pick your battles. Prioritize your
needs. Ask politely once for really important things, then plead again a
few days later.
5) Learn how to use an internet search engine. Try to find information
before you ask. The results may be hard to understand or confusing and be
careful about reading snippets without taking in some of the larger
context. But then your question will be better defined. Bonus if you can
quote a web page as part of your question.
6) Some folks want there to be a "bill of rights", but you don't have any
"rights" because there are no authority figures at Apache to enforce those
rights. Any "violations" have to be dealt with "socially". You can seek
help from the IPMC or even the board, but even they are volunteers and
will try to address the problem socially as well. You can expect and
demand respectful discourse, but sometimes tempers will boil over. That
happens in many workplaces, homes and other gatherings of people. Expect
it here as well, even more so sometimes, as there are relatively few
face-to-face encounters to encourage civility and limit chances of
mis-interpretation.
7) Your mentors may get too busy to follow the details of activity in your
podling. Use the [MENTOR] tag in the subject to try to catch their
attention. Escalate to the Incubator IPMC if they still don't have time
to respond.
8) Embrace diversity. Every podling is a little bit different and your
new podling may not exactly match up against existing documentation or
prior history. Ask for guidance, keep in mind that answers may vary, and
make your decision keeping these things in mind.
A) The primary goal is to cover your and Apache's butt legally. This may
require you to change build scripts and release packages in a way that is
painful for you and your customers.
B) Apache only officially releases source code. This may be a pain point
for any existing customers used to downloading binary packages.
C) At Apache, open source isn't just about making released source code
available. It is about trying to get the community involved early and
often before the source code is "release-ready".
9) Expect the unexpected. Sometimes, a document you find may be
out-of-date, and/or mention things that don't apply to you and when you
ask about it, you'll get a totally surprising answer.
10) Expect a ton of email. The temptation will be to unsubscribe from
some of the lists you are told to subscribe to, but it is important to
learn how to filter out stuff and skim other stuff as it helps you learn
about the people and personalities you will be dealing with
post-graduation on occasion, and if you end up on your project's PMC, you
will be responsible for mining important information from that email
stream.
Now this may seem like it should make you run away screaming, but it all
adds up to one thing: This is the "cost" of getting a group of volunteers
to provide free software to a community of developers and users. You are
doing a good deed by coming to Apache. You could just go to GitHub, but
Apache provides some legal and logistical processes that should make your
customers feel more secure that the code you want to work on will be
available to the customer "forever" without fear that some individual can
disappear and sink the whole ship, or some legal issue will arise later.
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] PodlingBillOfRights
Posted by Benson Margulies <bi...@gmail.com>.
A simple alternative is 'expectation'. However, I have no problem with
using it the way Joe wrote it.
On Tue, Jun 18, 2013 at 7:27 PM, Ross Gardler <rg...@opendirective.com>wrote:
> I did read the topmatter, but I still felt it was a concern. It's not
> just about mentors, that was just one example of a potential problem.
>
> Specifically the document currently says "podlings have a right to
> expect active participation and guidance from their mentors" - I fully
> support this, but as Upayavira asks, what can the IPMC do if this is
> not the case and no other mentors step up?
>
> I agree with your statement in this thread that mentoring is a
> "best-effort attempt based on volunteer availability not something we
> should commit to in a "Bill of Rights". I am not suggesting we commit
> to anything. Quite the opposite, I'm concerned that as your document
> is currently written it can be read as being a commitment (even with
> the topmatter making this explicit).
>
> It's hard to resolve without making your whole document just a bunch
> of words on a page. Maybe the topmatter is enough. Maybe I'm being too
> cautious.
>
> Anyway, as I said, on balance I really like this, if someone smart can
> wordsmith it then great. If not lets adopt it anyway.
>
> Ross
>
> On 19 June 2013 00:13, Joe Schaefer <jo...@yahoo.com> wrote:
> > Did you read the topmatter disclaimer about the terminology?
> > Anyway no podling has a guaranteed "right" to a sufficient number
> > of mentors, that's why I didn't bother addressing Upayavira's
> > concern. That is a best-effort attempt based on volunteer availability
> > not something we should commit to in a "Bill of Rights".
> >
> >
> >
> > ----- Original Message -----
> >> From: Ross Gardler <rg...@opendirective.com>
> >> To: general@incubator.apache.org; Joe Schaefer <jo...@yahoo.com>
> >> Cc:
> >> Sent: Tuesday, June 18, 2013 7:09 PM
> >> Subject: Re: [DISCUSS] PodlingBillOfRights
> >>
> >> Joe, this is (in general) great. I feel I could pick a few holes and
> >> make a few suggestions but they are mostly insignificant so I'll
> >> refrain from doing so.
> >>
> >> I do have one concern I want to air. Unfortunately I don't have a
> >> suggestion for improvement so am happy for you to ignore it, but maybe
> >> someone else has a bright idea.
> >>
> >> My concern is the use of the word "right". We are a volunteer
> >> organisation. Telling a podling they have a "right" to Foo and Bar
> >> might set the wrong tone. Upayavira appears to be thinking something
> >> similar (unless I'm misinterpreting him) when he asks:
> >>
> >> "I guess a question that it would be worth clarifying - what happens to
> a
> >> perfectly reasonable podling who's mentors resign/go awol, when the
> >> Incubator PMC cannot recruit replacements? Can we make any promises at
> >> that point?"
> >>
> >> Perhaps we can use a slightly softer word - perhaps I'm being too
> cautious.
> >>
> >> On 16 June 2013 15:16, Joe Schaefer <jo...@yahoo.com> wrote:
> >>> Since I realize that most of you can't be
> >>> bothered to look at the wiki page I created ;-),
> >>> I'll go ahead and post the current content
> >>> here for commentary. I hope the bulk of it
> >>> is non-controversial, though some of it may
> >>> not belong on the page...
> >>>
> >>>
> >>> ------------------------------------------------
> >>> First a clarification- as provisional constructs of the Incubator PMC,
> >> podlings have no official standing in the corporation known as The
> Apache
> >> Software Foundation. So technically, it is a farce to claim that
> podlings have
> >> any formal rights whatsoever. What we write about here are promises and
> >> covenants the Incubator PMC will make a good-faith effort to honor.
> >>>
> >>> 1. First, podlings have a right to expect active participation and
> >> guidance from their mentors. That minimally includes participation in
> release
> >> votes, discussions and votes on new personnel, and signing off on a
> >> podling's quarterly reports.
> >>>
> >>>
> >>> 2. Mentoring is done solely for the podling's benefit, and as such
> >> podlings have the right to fire mentors for any reason by a majority
> consensus
> >> vote on their private list. Just don't be denigrating about it, since
> >> mentors are always volunteers and not paid staff.
> >>>
> >>>
> >>> 3. Podlings who find themselves in need of additional mentors
> have the
> >> right to ask general@incubator for more mentors to volunteer.
> >>>
> >>>
> >>> 4. Podlings have the right to expect their quarterly reports to be
> >> read, reviewed, and critiqued by "shepherds" on the Incubator PMC, who
> >> are typically outside the podling's set of mentors.
> >>>
> >>>
> >>> 5. Podlings have the right to express private concerns about
> anything
> >> related to their incubation to the Incubator Ombudsman
> >> <om...@incubator>, who will handle such communications as if they
> were
> >> sent anonymously.
> >>>
> >>>
> >>> 6. Podlings have the right to express their opinions concerning
> their
> >> incubation efforts post-graduation (or post-mortem) in the form of an
> anonymous
> >> survey.
> >>>
> >>>
> >>> 7. Podlings have the right to ignore commentary made on
> >> general@incubator in the middle of a VOTE thread, especially during
> releases.
> >> Reminder- release votes are a majority consensus vote, so seeing a few
> -1's
> >> occasionally is expected and often ignorable by the RM should they
> otherwise see
> >> a majority of at least 3 binding IPMC votes.
> >>>
> >>>
> >>> 8. Podling committers have the right to remain unsubscribed to
> >> general@incubator. Any relevant policy/process changes will be passed
> along by
> >> the podling's mentors.
> >>> ------------------------------------------------
> >>>
> >>> Comments and critiques welcome. I'd like to
> >>> move the ball forward to a ceremonial endorsement
> >>> VOTE on this over the course of the remainder
> >>> of June, so please be constructive!
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [DISCUSS] PodlingBillOfRights
Posted by Ross Gardler <rg...@opendirective.com>.
I did read the topmatter, but I still felt it was a concern. It's not
just about mentors, that was just one example of a potential problem.
Specifically the document currently says "podlings have a right to
expect active participation and guidance from their mentors" - I fully
support this, but as Upayavira asks, what can the IPMC do if this is
not the case and no other mentors step up?
I agree with your statement in this thread that mentoring is a
"best-effort attempt based on volunteer availability not something we
should commit to in a "Bill of Rights". I am not suggesting we commit
to anything. Quite the opposite, I'm concerned that as your document
is currently written it can be read as being a commitment (even with
the topmatter making this explicit).
It's hard to resolve without making your whole document just a bunch
of words on a page. Maybe the topmatter is enough. Maybe I'm being too
cautious.
Anyway, as I said, on balance I really like this, if someone smart can
wordsmith it then great. If not lets adopt it anyway.
Ross
On 19 June 2013 00:13, Joe Schaefer <jo...@yahoo.com> wrote:
> Did you read the topmatter disclaimer about the terminology?
> Anyway no podling has a guaranteed "right" to a sufficient number
> of mentors, that's why I didn't bother addressing Upayavira's
> concern. That is a best-effort attempt based on volunteer availability
> not something we should commit to in a "Bill of Rights".
>
>
>
> ----- Original Message -----
>> From: Ross Gardler <rg...@opendirective.com>
>> To: general@incubator.apache.org; Joe Schaefer <jo...@yahoo.com>
>> Cc:
>> Sent: Tuesday, June 18, 2013 7:09 PM
>> Subject: Re: [DISCUSS] PodlingBillOfRights
>>
>> Joe, this is (in general) great. I feel I could pick a few holes and
>> make a few suggestions but they are mostly insignificant so I'll
>> refrain from doing so.
>>
>> I do have one concern I want to air. Unfortunately I don't have a
>> suggestion for improvement so am happy for you to ignore it, but maybe
>> someone else has a bright idea.
>>
>> My concern is the use of the word "right". We are a volunteer
>> organisation. Telling a podling they have a "right" to Foo and Bar
>> might set the wrong tone. Upayavira appears to be thinking something
>> similar (unless I'm misinterpreting him) when he asks:
>>
>> "I guess a question that it would be worth clarifying - what happens to a
>> perfectly reasonable podling who's mentors resign/go awol, when the
>> Incubator PMC cannot recruit replacements? Can we make any promises at
>> that point?"
>>
>> Perhaps we can use a slightly softer word - perhaps I'm being too cautious.
>>
>> On 16 June 2013 15:16, Joe Schaefer <jo...@yahoo.com> wrote:
>>> Since I realize that most of you can't be
>>> bothered to look at the wiki page I created ;-),
>>> I'll go ahead and post the current content
>>> here for commentary. I hope the bulk of it
>>> is non-controversial, though some of it may
>>> not belong on the page...
>>>
>>>
>>> ------------------------------------------------
>>> First a clarification- as provisional constructs of the Incubator PMC,
>> podlings have no official standing in the corporation known as The Apache
>> Software Foundation. So technically, it is a farce to claim that podlings have
>> any formal rights whatsoever. What we write about here are promises and
>> covenants the Incubator PMC will make a good-faith effort to honor.
>>>
>>> 1. First, podlings have a right to expect active participation and
>> guidance from their mentors. That minimally includes participation in release
>> votes, discussions and votes on new personnel, and signing off on a
>> podling's quarterly reports.
>>>
>>>
>>> 2. Mentoring is done solely for the podling's benefit, and as such
>> podlings have the right to fire mentors for any reason by a majority consensus
>> vote on their private list. Just don't be denigrating about it, since
>> mentors are always volunteers and not paid staff.
>>>
>>>
>>> 3. Podlings who find themselves in need of additional mentors have the
>> right to ask general@incubator for more mentors to volunteer.
>>>
>>>
>>> 4. Podlings have the right to expect their quarterly reports to be
>> read, reviewed, and critiqued by "shepherds" on the Incubator PMC, who
>> are typically outside the podling's set of mentors.
>>>
>>>
>>> 5. Podlings have the right to express private concerns about anything
>> related to their incubation to the Incubator Ombudsman
>> <om...@incubator>, who will handle such communications as if they were
>> sent anonymously.
>>>
>>>
>>> 6. Podlings have the right to express their opinions concerning their
>> incubation efforts post-graduation (or post-mortem) in the form of an anonymous
>> survey.
>>>
>>>
>>> 7. Podlings have the right to ignore commentary made on
>> general@incubator in the middle of a VOTE thread, especially during releases.
>> Reminder- release votes are a majority consensus vote, so seeing a few -1's
>> occasionally is expected and often ignorable by the RM should they otherwise see
>> a majority of at least 3 binding IPMC votes.
>>>
>>>
>>> 8. Podling committers have the right to remain unsubscribed to
>> general@incubator. Any relevant policy/process changes will be passed along by
>> the podling's mentors.
>>> ------------------------------------------------
>>>
>>> Comments and critiques welcome. I'd like to
>>> move the ball forward to a ceremonial endorsement
>>> VOTE on this over the course of the remainder
>>> of June, so please be constructive!
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] PodlingBillOfRights
Posted by Joe Schaefer <jo...@yahoo.com>.
Did you read the topmatter disclaimer about the terminology?
Anyway no podling has a guaranteed "right" to a sufficient number
of mentors, that's why I didn't bother addressing Upayavira's
concern. That is a best-effort attempt based on volunteer availability
not something we should commit to in a "Bill of Rights".
----- Original Message -----
> From: Ross Gardler <rg...@opendirective.com>
> To: general@incubator.apache.org; Joe Schaefer <jo...@yahoo.com>
> Cc:
> Sent: Tuesday, June 18, 2013 7:09 PM
> Subject: Re: [DISCUSS] PodlingBillOfRights
>
> Joe, this is (in general) great. I feel I could pick a few holes and
> make a few suggestions but they are mostly insignificant so I'll
> refrain from doing so.
>
> I do have one concern I want to air. Unfortunately I don't have a
> suggestion for improvement so am happy for you to ignore it, but maybe
> someone else has a bright idea.
>
> My concern is the use of the word "right". We are a volunteer
> organisation. Telling a podling they have a "right" to Foo and Bar
> might set the wrong tone. Upayavira appears to be thinking something
> similar (unless I'm misinterpreting him) when he asks:
>
> "I guess a question that it would be worth clarifying - what happens to a
> perfectly reasonable podling who's mentors resign/go awol, when the
> Incubator PMC cannot recruit replacements? Can we make any promises at
> that point?"
>
> Perhaps we can use a slightly softer word - perhaps I'm being too cautious.
>
> On 16 June 2013 15:16, Joe Schaefer <jo...@yahoo.com> wrote:
>> Since I realize that most of you can't be
>> bothered to look at the wiki page I created ;-),
>> I'll go ahead and post the current content
>> here for commentary. I hope the bulk of it
>> is non-controversial, though some of it may
>> not belong on the page...
>>
>>
>> ------------------------------------------------
>> First a clarification- as provisional constructs of the Incubator PMC,
> podlings have no official standing in the corporation known as The Apache
> Software Foundation. So technically, it is a farce to claim that podlings have
> any formal rights whatsoever. What we write about here are promises and
> covenants the Incubator PMC will make a good-faith effort to honor.
>>
>> 1. First, podlings have a right to expect active participation and
> guidance from their mentors. That minimally includes participation in release
> votes, discussions and votes on new personnel, and signing off on a
> podling's quarterly reports.
>>
>>
>> 2. Mentoring is done solely for the podling's benefit, and as such
> podlings have the right to fire mentors for any reason by a majority consensus
> vote on their private list. Just don't be denigrating about it, since
> mentors are always volunteers and not paid staff.
>>
>>
>> 3. Podlings who find themselves in need of additional mentors have the
> right to ask general@incubator for more mentors to volunteer.
>>
>>
>> 4. Podlings have the right to expect their quarterly reports to be
> read, reviewed, and critiqued by "shepherds" on the Incubator PMC, who
> are typically outside the podling's set of mentors.
>>
>>
>> 5. Podlings have the right to express private concerns about anything
> related to their incubation to the Incubator Ombudsman
> <om...@incubator>, who will handle such communications as if they were
> sent anonymously.
>>
>>
>> 6. Podlings have the right to express their opinions concerning their
> incubation efforts post-graduation (or post-mortem) in the form of an anonymous
> survey.
>>
>>
>> 7. Podlings have the right to ignore commentary made on
> general@incubator in the middle of a VOTE thread, especially during releases.
> Reminder- release votes are a majority consensus vote, so seeing a few -1's
> occasionally is expected and often ignorable by the RM should they otherwise see
> a majority of at least 3 binding IPMC votes.
>>
>>
>> 8. Podling committers have the right to remain unsubscribed to
> general@incubator. Any relevant policy/process changes will be passed along by
> the podling's mentors.
>> ------------------------------------------------
>>
>> Comments and critiques welcome. I'd like to
>> move the ball forward to a ceremonial endorsement
>> VOTE on this over the course of the remainder
>> of June, so please be constructive!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [DISCUSS] PodlingBillOfRights
Posted by Ross Gardler <rg...@opendirective.com>.
Joe, this is (in general) great. I feel I could pick a few holes and
make a few suggestions but they are mostly insignificant so I'll
refrain from doing so.
I do have one concern I want to air. Unfortunately I don't have a
suggestion for improvement so am happy for you to ignore it, but maybe
someone else has a bright idea.
My concern is the use of the word "right". We are a volunteer
organisation. Telling a podling they have a "right" to Foo and Bar
might set the wrong tone. Upayavira appears to be thinking something
similar (unless I'm misinterpreting him) when he asks:
"I guess a question that it would be worth clarifying - what happens to a
perfectly reasonable podling who's mentors resign/go awol, when the
Incubator PMC cannot recruit replacements? Can we make any promises at
that point?"
Perhaps we can use a slightly softer word - perhaps I'm being too cautious.
On 16 June 2013 15:16, Joe Schaefer <jo...@yahoo.com> wrote:
> Since I realize that most of you can't be
> bothered to look at the wiki page I created ;-),
> I'll go ahead and post the current content
> here for commentary. I hope the bulk of it
> is non-controversial, though some of it may
> not belong on the page...
>
>
> ------------------------------------------------
> First a clarification- as provisional constructs of the Incubator PMC, podlings have no official standing in the corporation known as The Apache Software Foundation. So technically, it is a farce to claim that podlings have any formal rights whatsoever. What we write about here are promises and covenants the Incubator PMC will make a good-faith effort to honor.
>
> 1. First, podlings have a right to expect active participation and guidance from their mentors. That minimally includes participation in release votes, discussions and votes on new personnel, and signing off on a podling's quarterly reports.
>
>
> 2. Mentoring is done solely for the podling's benefit, and as such podlings have the right to fire mentors for any reason by a majority consensus vote on their private list. Just don't be denigrating about it, since mentors are always volunteers and not paid staff.
>
>
> 3. Podlings who find themselves in need of additional mentors have the right to ask general@incubator for more mentors to volunteer.
>
>
> 4. Podlings have the right to expect their quarterly reports to be read, reviewed, and critiqued by "shepherds" on the Incubator PMC, who are typically outside the podling's set of mentors.
>
>
> 5. Podlings have the right to express private concerns about anything related to their incubation to the Incubator Ombudsman <om...@incubator>, who will handle such communications as if they were sent anonymously.
>
>
> 6. Podlings have the right to express their opinions concerning their incubation efforts post-graduation (or post-mortem) in the form of an anonymous survey.
>
>
> 7. Podlings have the right to ignore commentary made on general@incubator in the middle of a VOTE thread, especially during releases. Reminder- release votes are a majority consensus vote, so seeing a few -1's occasionally is expected and often ignorable by the RM should they otherwise see a majority of at least 3 binding IPMC votes.
>
>
> 8. Podling committers have the right to remain unsubscribed to general@incubator. Any relevant policy/process changes will be passed along by the podling's mentors.
> ------------------------------------------------
>
> Comments and critiques welcome. I'd like to
> move the ball forward to a ceremonial endorsement
> VOTE on this over the course of the remainder
> of June, so please be constructive!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org