launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On Tue, 2010-09-21 at 15:35 -0500, Edwin Grubbs wrote:
> The loose connection between project groups and projects is another
> situation that works fine for open source projects with community
> ownership but is not what a company is going to want for a projects
> they control.

bug 58297 is very old. While we are open now, we question any project
that tries to join ours. Project owners have been complaining for years
that people are adding projects and messing up their series and
milestone reports. The subprojects that do this do not know that doing
this also gives the PG control over bugs. In summary we built a
mechanism that is both for control and affiliation, and it does both
rather poorly.

> Auditing access to all aspects of a single project will work fine for
> organizations with just one project, but it will break down when they
> add more. We could give Project Groups two very different behaviors
> depending on whether it is meant to hold public or private projects,
> or we could think of the organization as the object that controls the
> privacy of all other objects belonging to it and can audit them. An
> organization could just be another team with added features enabled. 

I favor making making the existing structure a control mechanism. I like
the term "Organization" for mechanism for control. An Organization want
the power to create a series or milestone and see it propagate to the
projects.

Affiliation  is more like tags because their number and definition will
vary with the inventiveness of the community. I rejected two project
group requests recently because the user did not have control of the
projects he wanted to show were affiliated. The owners were not
interested in giving him power over their projects, though they all
agreed the projects were related.


-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part