Bugzilla permissions - cla_done required?

[Karsten 'quaid' Wade]

On Sun, 2008-02-10 at 23:14 -0500, Jon Stanley wrote:
> Bringing up an old topic here that was recently decided in FESCo[1]
> and also discussed at FUDCon RDU  - escalating to FAB per request.
> 
> As most of you know, I'm leading an effort to relaunch the bug triage
> project.  We had decided that cla_done would be a requirement for a
> few reasons:
> 
> 1)  Ability to use items in release notes, documentation, etc.
>   a)  Although anyone can make a comment on the bug, only folks in the
> 'fedorabugs' group in FAS (which maps to fedora_contrib in bugzilla)
> can set the fedora_requires_release_note flag.   This gets the bug
> special attention from the docs team.
> 2)  Wiki edit access requirement.  In the future this will be going to
> a click-through CLA, which I think is also appropriate for 1.

Here is the most comprehensive guide to how we apply the CLA:

http://fedoraproject.org/wiki/Legal/CLAAcceptanceHierarchies

The cut-off line for GPG-signed is, "Does this contribution go directly
into source control for the distro?"  While the higher level of
assurance is for when a contribution goes directly into a distro, any
contribution needs to be under some kind of agreement.

Bugzilla is not on there for several reasons, as I recall.  The fact
that bugzilla.redhat.com is used by Red Hat for business makes it
difficult for Fedora to dictate the terms of usage.  The Fedora CLA
can't really be a barrier to e.g. getting a bugzilla.r.c account.

Also, bz work falls somewhere between "Mailing list member" and "Wiki
contributor."  The former is a discussion and information exchange, the
later is a contribution of content, such as a patch.

Typically, the bz report itself has served the purpose of making it
clear the patch was a contribution, etc.

For bug triagers, it seems to make sense to, as you say, capture them
with a click-through CLA.  That way we can be assured that content can
then be moved to e.g. source control.

> There's also the argument that signing the CLA is a (minor) technical
> hurdle for new triagers to overcome.  While this is valuable, I also
> think that other things could be used in it's place (open to
> suggestions here) to demonstrate technical ability.

Yes, we hear a lot that it is too difficult.

We've got a good doc on how-to:

http://fedoraproject.org/wiki/DocsProject/UsingGpg

I'm not arguing that it's ideal, but it is a fair barrier at a certain
point.  Maybe not for triagers, though.

> The argument that came to light, and was discussed on
> fedora-devel-list[2] that FAS requires "too much" personal information
> (i.e. home address, phone number, etc) in order to sign up for an
> account and sign the CLA.  Access to bugzilla is controlled via FAS,
> therefore, without an FAS account, access to triage bugs is a
> non-starter.

I'm going to trust Red Hat's lawyers when they say they need that
information in order to have the level of assurance to distribute a
contribution.  If we need to get a hold of a contributor for any
legitimate reason, it'll be a bummer if they really don't live at 123
Main Street, Anywhere, USA.

> So the question here is whether cla_done is required in order to
> belong to the 'fedorabugs' group in FAS?  My vote is 'yes' for the
> reasons listed above for now, revisit with FAS2, as was decided at
> FESCo.

I missed this part.  FESCo has already decided how they want this
handled?  And some folks aren't happy with that situation?

Without FAS2, I don't see a way around this.  That is, I guess something
of a click-through CLA could be hacked up, by why spend the time on that
over finishing FAS2?

- Karsten
-- 
Karsten Wade, Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20080211/d0d9d4f9/attachment.sig>