XAP IRC Minutes 20060615

[Scott Boyd <sc...@gmail.com>]

[1:55] * Now talking in #xap

[1:55] * Statistics: 1 Ops, 3 Users (Total: 4)

[1:55] [freenode-connect VERSION]

[1:55] * coach (n=coach@64.221.88.146.ptr.us.xo.net) has joined #xap

[1:57] * bbuffone (n=bbuffone@64.221.88.146.ptr.us.xo.net) has joined #xap

[2:01] <coach> Scribe: Scott Boyd.

[2:02] <coach> Agenda:

[2:02] <coach>

[2:02] <coach> Identify scribe

[2:02] <coach> Quick status update

[2:02] <coach> Nexaweb code commit/packaging etc status –Coach

[2:02] <coach> Apache infrastructure status (account setup, email
setup, SVN, SSH, etc) – Cliff Schmidt
[2:02] <coach> Apache Process Overview
[2:02] <coach> Cliff Schmidt
[2:02] <coach> XAP process discussion
[2:02] <coach> Q & A
[2:03] * JMargaris (n=jmargari@64.221.88.146.ptr.us.xo.net) has joined #xap
[2:04] <sboyd> Coach:  quick status update from nexaweb: initial code,
demos, samples and documentation are ready for commit
[2:06] <JMargaris> yes, it does
[2:07] <sboyd> Cliff: reviewed the distinction of the 4 mailing lists
[2:07] <sboyd> Cliff: status of contributor accounts: everyone but
Animesh and John's accounts are set up because the contributor forms
were not recieved by the secretary in time
[2:08] <sboyd> Cliff: SVN and apache infrastructure should be set up
and ready to go today, so tomorrow we can move forward with the
initial code contribution
[2:09] <sboyd> Cliff: Defect tracking (Jira) needs to be set up as
well, and Cliff will take care of it
[2:09] <coach> Action: coach to send website draft  to Cliff for
review and commit.
[2:11] <sboyd> Cliff:  many projects use SVN to store both the source
for the website and the result for the build.  In these cases, the
result of the build gets checked into another repository to get
published.
[2:12] <sboyd> Bob: what's required to trigger the publish?
[2:12] <sboyd> Cliff: some specific permissions/Karma to the right repository
[2:13] <sboyd> Coach: an automated task looks for updates nightly, so
its just a matter of getting the changes to this location for them to
get published
[2:14] <sboyd> Cliff: many projects assign a release manager.  you
don't have to pick anyone now, but often projects have a single person
who coordinates this effort so they can get good at it.
[2:16] <sboyd> Cliff: switching gears to talk about the apache
process.  ApacheCon (in Dublin in a few weeks) has many helpful
sessions on various apache processes. Check out www.apachecon.com for
more details.
[2:17] <sboyd> Cliff: lets review some apache documents
[2:18] <sboyd> Cliff: How the ASF works --
http://www.apache.org/foundation/how-it-works.html
[2:19] <sboyd> Cliff: Being a committer is having Karma to a certain
part of the project to make code changes.  Being on PMC is having the
authority to make decisions at the Project level - often made up of a
large number of committers.  Different projects run it differently.
[2:19] * peter_eacmen (n=peter_ea@70.134.93.37) has joined #xap
[2:20] <sboyd> Cliff: As an incubated project, the XAP PMC is the
Incubator project.  The only things the Incubator PMC will be
concerned with are legal issues and making sure that the project is
run consistantly with other Apache projects
[2:21] <peter_eacmen> hey guys
[2:21] <JMargaris> Hey Peter
[2:21] <coach> Hey peter. Can you call in?
[2:21] <peter_eacmen> i am in
[2:22] <sboyd> Cliff: The PMC also gets involved in the graduation
process.  This process usually takes around 6-12 months, and may
result in the project moving under the auspice of another project, or
to become a top level project in its own right.
[2:22] <peter_eacmen> i connected late
[2:22] <sboyd> Michael Turyn: what are the requirements for graduation?
[2:22] <coach> peter - can you see the IRC log from the part of the
meeting that you missed?
[2:23] <peter_eacmen> is it posted somewhere?
[2:24] <coach> It should be in the IRC channel. If you don't see it,
that means IRC channel only displays the latest content to you when
you joined  in?
[2:24] <sboyd> Cliff: the main thing aside from the legal issues
around licensing, is the community aspect.  Has this project shown
over many months that its encouraging to new people showing up, the
meritocracy values are demonstrated, collaboration etc...
[2:24] <JMargaris> we can post it someplace later or send it to you
[2:25] <peter_eacmen> yah i am just using X-Chat, not sure how to do that
[2:25] <sboyd> Cliff: also a requirement that there are at least 3
different groups of interest guiding the project -- all Nexaweb
employees/contractors would count as a single interest group
[2:25] <sboyd> Cliff: additinoinally, have other people been attracted
to the project and become active members
[2:25] <sboyd> Cliff: the chair of each PMC is an officer of the foundation
[2:27] <sboyd> Cliff: every group needs a place for private
conversations (e.g. someone is distruptive in the general mailing
list, should we grant more karma to another person), these
conversations should be held in the private mailing group with the
prefix ppmc
[2:27] <sboyd> Cliff: this also gets people in the habit of figuring
out how PMCs work
[2:28] <sboyd> Cliff: IRC is better than phonecalls because we have
people who speak other languages and live in different timezones
[2:29] <sboyd> Cliff: Decision making: for something like a release,
you will have a vote.  Votes usually have a +1, +0, 0, -0, -1 ranging
from enthusiastic yes to a veto.
[2:30] <sboyd> Coach: What is the process for exercising veto right?
Are there any guidelines around vetos?  I could see the possibility
that a veto may hold progress in some cases.
[2:32] <sboyd> Cliff: vetos are very rare.  Sometimes people will give
a -1 with a disclaimer on something that should be fixed.  An example
may be on a vote to release, one person votes -1 because some set of
files don't have the correct license disclaimers, but they'll change
their vote once the issue is addressed
[2:33] <sboyd> Coach: to summarize, a veto should always have a
helpful suggestion to resolve the percieved problem
[2:34] <sboyd> Cliff: back to graduation - diversity in committers is
good, but Apache doesn't really look at who your employer is.  Apache
realizes that the initial code contribution comes from Nexaweb, and
legally its important to recognize this fact.
[2:35] <sboyd> Cliff: However, contributors are judged on their own
contributions.  Do they seem to be acting for the good of the company,
or for the good of the project?
[2:36] <cliffs> http://apache.org/dev/#committers
[2:36] <sboyd> Cliff: its a great thing if the success of the project
is helpful to the success of a sponsoring company, but the companies
interest should not hijack the progress of the project.
[2:37] <sboyd> Cliff:  read through all the links on the committers
page, and glance at the rest of the page (e.g. releases, managing the
project website)
[2:37] <cliffs> http://incubator.apache.org/incubation/Incubation_Policy.html
[2:38] <sboyd> Cliff: Incubation policy - some of this I've already covered
[2:39] <sboyd> Cliff: overview of the process - incubated project,
candidate project, sometimes referred to as a "podling", takes about
6-9 months to graduate from the incubator
[2:39] <sboyd> Cliff: since none of the top level projects domain made
sense to sponser XAP, the Incubator project was chosen to incubate XAP
[2:40] <sboyd> Cliff: if Kabuki had taken off a year ago and had
graduated to a top level project, XAP would have made sense to
incubate under Kabuki
[2:41] <sboyd> Bob: What happens when a project stagnates?  For
example, we have a dependency on the Kabuki project
[2:42] <sboyd> Cliff: first thing to do is to subscribe to their dev
list - express our interest in the project and find out whats going
on?
[2:42] <sboyd> Bob: is it possible to fail the incubator?
[2:43] <sboyd> Cliff: if there is no activity, and a lot of time goes
by, projects may be dropped from the incubator.  Sometimes though, it
just takes a while for a project to get into a rhythm of activity.  In
early stages, its because the committers aren't contributing.  In
later stages, its because the project isn't making any progress.
[2:44] <sboyd> Cliff: Review -- every project at apache, every one of
the 35 top level projects, we have over 100 products, but just about
35 top level projects
[2:45] <sboyd> Cliff: each PMC needs to make a summary report to the
apache board about activity, legal issues, etc about whats going on
with the project
[2:46] <sboyd> Cliff: because the Incubator project has so many
sub-projects, it will send out a request for status to all its
sub-projects.  New projects like XAP require a report every single
month.  It might be best to come from a committer, but I can take a
stab at it for this month.
[2:47] <sboyd> Cliff: usually this request is sent to the general
incubator list, so the more active participants in a project should be
subscribed to this list to be aware of issues like this
[2:47] <sboyd> Coach: how do we add XAP to the list of incubated projects?
[2:48] <sboyd> Cliff: this will get taken care of in the next few days
along with the infrastructure setup
[2:49] <sboyd> Cliff: I'll set this up initially, but you guys as
committers should make sure this is updated.  I recommend updating it
with each monthly report, and especially when you push for graduation
after 6-9 months before you ask the PMC board to review you.
[2:50] <sboyd> Cliff: we need to do a monthly report for the first 3
months, but after that once every 3 months
[2:51] <sboyd> Cliff: podling constraints is a section in the incubator policy
[2:52] <sboyd> Cliff: branding is important -- we're a brand new
project just starting up, no history of past projects.  Apache doesn't
want a bad project to reflect negatively on Apache, so there is a
disclaimer for incubated projects and some rules for file naming etc..
[2:53] <cliffs> http://incubator.apache.org/incubation/Process_Description.html
[2:54] <cliffs>
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html
[2:54] <sboyd> Cliff: release - the PMC board will evaluate on
releases, version is up to us, though 1.0 can stir controversy before
graduation.  However, if we feel the codebase reflects 1.0, then we
should bring it up with the PMC.
[2:54] <sboyd> Cliff: the sponsor PMC for XAP is the incubator PMC,
the champion is Cliff, and there are 3 mentors
[2:57] <sboyd> Michael: would it make sense to get another sponsor
because there are so many under incubator?
[2:58] <sboyd> Cliff: that only makes sense if there is a tight
technology fit between the top level project and the incubated project
[2:59] <sboyd> Coach: should we have a weekly or bi-weekly IRC chat?
[2:59] * rdonkin
(n=rdonkin@82-38-65-173.cable.ubr06.brad.blueyonder.co.uk) has joined
#xap
[2:59] <sboyd> Michael: bi
[2:59] <sboyd> Peter: bi
[3:00] <rdonkin> looks like i got my timezones wrong :-/
[3:00] <rdonkin> a good start - not
[3:00] <sboyd> Coach: OK, tentatively, lets move forward with
bi-weekly 100% IRC chats
[3:00] <JMargaris> We are going to post notes to the dev mailing list
[3:00] <rdonkin> sorry
[3:01] <coach> Not a problem. Welcome Rob.
[3:01] <coach> Rob: can you call in on phone to speak with people for
a few seconds?
[3:01] <rdonkin> possibly...
[3:01] <rdonkin> skype permitting
[3:02] <rdonkin> it'll take me a minute or two to set up my laptop
[3:03] <sboyd> Cliff: best thing to do when scheduling meetings is to
put meeting times in GMT - this makes it easier for people outside of
the US to schedule their time
[3:03] <coach> ok. We'have basically finished the call today. The
minutes wll be posted to the xap-dev@incubator.apache.org.
[3:05] <rdonkin> having trouble with Skype :-/
[3:05] <rdonkin> doesn't like my password
[3:05] <coach> Rob: thanks. Let's talk some other time.
[3:05] <rdonkin> might take a while to sort. sorry.
[3:06] <coach> bye.
[3:06] <rdonkin> bye
[3:06] <sboyd> later

Re: XAP IRC Minutes 20060615

[robert burrell donkin <rd...@apache.org>]

On Thu, 2006-06-15 at 12:23 -0700, Scott Boyd wrote:

<snip>IRC</snip>

cheers

apologies for messing up the timezone :-/

- robert

Re: XAP IRC Minutes 20060615

[robert burrell donkin <rd...@apache.org>]

(i have a few little comments that i've been meaning to write up for a
while now. probably better this way since it doesn't break up cliff's
flow. )

On Thu, 2006-06-15 at 12:23 -0700, Scott Boyd wrote:

<snip>

> [2:29] <sboyd> Cliff: Decision making: for something like a release,
> you will have a vote.  Votes usually have a +1, +0, 0, -0, -1 ranging
> from enthusiastic yes to a veto.
> [2:30] <sboyd> Coach: What is the process for exercising veto right?
> Are there any guidelines around vetos?  I could see the possibility
> that a veto may hold progress in some cases.

that is entirely the purpose of a veto :-)

social conventions often prove surprisingly strong at binding a group.
there are very few rules or process exercised around the issue of a vote
- but that's the point. there can be no hiding - a veto is a strong
public action with consequences. 

collaborative development requires cooperation. occasionally, developers
fall out for various reasons. reputation has proved to be a stronger
tool in keeping exchanges civil than rules and process. as much as
possible at apache is a matter for public record. the public can judge
every exchange.

> [2:32] <sboyd> Cliff: vetos are very rare.  Sometimes people will give
> a -1 with a disclaimer on something that should be fixed.  An example
> may be on a vote to release, one person votes -1 because some set of
> files don't have the correct license disclaimers, but they'll change
> their vote once the issue is addressed

+1 

(i had to do this earlier this year)

> [2:33] <sboyd> Coach: to summarize, a veto should always have a
> helpful suggestion to resolve the percieved problem

i think i disagree a little. i would say that if you have a resolution
then commit it :-)

veto's are a bit like SHOUTING STOP VERY LOUDLY! it's rare that
circumstances demand this. shouting isn't very civilised so most of the
time a quiet word achieves more with less effort. 

so, if i see an issue with a particular commit, most of the time i'll
just commit a correction. if i don't feel confident (maybe i don't know
the committer very well or i'm just on unfamiliar territory), i'll reply
to the commit and raise my concerns. only when there is a pressing
necessity would i consider a veto. i don't think that i've every needed
to veto and personally rollback the commit (which is the ultimate
sanction).

and not all -1's are veto's. 

+1, +0. -0, -1 are also sometimes used in discursive mode (see above).
quicker to type and easier to read than yeh and so on. 

when a VOTE is by simple majority, -1 is just a negative vote to be
tallied against the +1's.

i'll probably post something about consensus (lazy and otherwise) sooner
or later. only when an action requires consensus (either socially or
processwise) is a -1 a veto. 

- robert