Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
From: "Noel J. Bergman" <noel@devtech.com>
To: <general@incubator.apache.org>
Subject: RE: [DISCUSS] Incubating Project Policy
Date: Mon, 5 Feb 2007 14:08:23 -0500
Message-ID: <NBBBJGEAGJAKLIDBKJOPEEMNMNAC.noel@devtech.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <8b3ce3790702050954r7f78b7a6la2cfe36d3b3dda7d@mail.gmail.com>
Importance: Normal

Ted Husted wrote:

> Noel J. Bergman wrote:
> > As noted by James Margaris, yourself, Bertrand, et al, this does not
> > actually address the issue where someone is committing co-workers'
> > work, rather than having the co-workers participating on-list.  We
> > are really looking to have those co-workers be the one's directly
> > posting to the mailing list or JIRA.  To get what you want, your
> > second paragraph should clarify that "first [posting] the submission"
> > means BY THE ACTUAL CONTRIBUTOR, not a proxy.

> In the "committing for employer under a CCLA" scenario, the co-workers
> have probably assigned all their rights to the code to their employer.
> Accordingly, the individual is not the contributor, the employer is
> the contributor.

No, no.  This defeats the real purpose.  We're not talking about IP.  OK,
perhaps some folks are, but the CLA means that the person making a commit
must be claiming to do so properly under the terms of the CLA.  If you
commit some code, I must assume that you are doing so with proper authority.
The CCLA exists to ensure that in a work-for-hire situation, that your
employer is confirming your ability to act under the terms of your CLA.

The real purpose is community building, and to make sure that all
discussions and decisions take place on the mailing list as part of the
community.  If the co-workers are working off-list and some agent is just
committing their collective work, that detracts from the ability to have all
of those internal discussions on-list as part of the community.

> If these co-workers want to participate,  they can. But, these
> individuals may or may not be authorized to discuss the code in
> public. It's easy to imagine an environment where a senior
> employee is trusted to contribute and discuss this work outside
> the office domain, while other employers have not yet earned that
> trust with their employer.

That iss something we need to encourage the employer to fix.  As noted
above, the scenario you envision is one rife with back-channel discussions
and decisions being made off-list, even if they are later ratified by the
community when the code is eventually committed.  But there is a difference
between collective development and collectively maintaining a public
repository.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org