On Thu, 2010-03-04 at 18:20 +0100, Danilo Šegan wrote: > > Branches: series branch > > ----------------------- ... > +1 Basically, we want to have a concept of "imported" project, and > perhaps having Registry Admins own it is a good indicator of such. > > I think we are going to run into a lot of complications when we start > considering LP hosted projects where they are using only some bits of > LP, yet other users want to use others as well (eg. branches and/or > translations).
Indeed. This is the reason why Edwin's proposal to change the Involvement portlet is confusing. Most people think of Launchpad as a project hosting service. I think it is better to think of Launchpad are a community hosting service. Projects are where communities often intersect and they must share. I have considered the case where the project does use Launchpad for hosting. If conflicts over series cannot be reconciled, I would allow anyone to create a series instead of the projects drivers. This will allow communities to work in parallel. This also invited forking which may be a false understanding since branches are also forks. > > Translations: enable imports > > ---------------------------- ... > > I want to permit any user to enable imports from the series branch > that is > > also linked to a source package. > > Is there a reason to limit it like this? My take would be similar to > above: for any Registry-owned project, anyone can set it up. For > projects with branches and unset translations, anyone can set it up. > Perhaps the second condition should also take the existence of a link > to a sourcepackage as well. I was thinking the users would have link to a source package first, but I think your suggestion is best. I think this will also reduce the number of users who want to import a project instead of translating the project already in Launchpad. > > I want this to be visible to the series > > release manager because I think he will be more willing to except > exports > > to he branch if he knew another community was helping him. > > Considering how we don't want to allow anyone to translate in LP once > translations are imported, allowing export is not going to be of much > use: whatever is imported would be exported as well. I do not understand this point. > > This may require > > users to enable Launchpad Translations, but I think the project's > use of > > Translations is separate from Ubuntu desire to get the latest > Translations. > > At the moment, it's perfectly possible to set up translations import > from a branch without "enabling" Launchpad Translations. And for the > benefits we are expecting in Ubuntu, that's just about enough. Ah! I was looking at the project, not the series. Okay, This is good. I can see I can do this for my projects, Registry Administrators, and projects owned by other users. This does not need a permission change, it just needs to made more prominent--this path requires knowledge. https://launchpad.net/ubuntu/lucid/+source/gedit > gedit HEAD series https://launchpad.net/gedit/head > Translations https://translations.launchpad.net/gedit/head > Set up branch synchronization > > Implementation notes > > .................... > > > > I think the proposed permission rules imply the return of the > despicable > > EditPersonLocation-style permission checker... > > > > class EditProductSomething(EditByOwnersOrAdmins): > > permission = 'launchpad.EditSomething' > > usedfor = IProduct > > > > def checkAuthenticated(self, user): > > """Anybody can edit something if it is not set.""" > > something = self.obj.something > > if something is None: > > return True > > else: > > return super(EditProductSomething, > self).checkAuthenticated(user) > > > > ...and the setup of some unique views to isolate this kind of > change. > > > > Since we are striving to remove the exceptional permission names, > this whole > > category of needs a name and story that is easy to test when we want > to > > reuse the permission name. We have a few cases of launchpad.append, > but I > > do not think that is this case. I also discount launchpad.moderate. > > This looks like a launchpad.Propose, or launchpad.Suggest. > > > > I have some reservation about this whole proposal--users cannot fix > their > > mistakes. This will lead to requests to other users to fix the data, > and lead > > to bug reports just like the reports to edit/delete comments. > > We may need to start thinking about "report this" functionality in LP. > Seeing how crowd-sourcing is critical to the success of our bridging > the > gap goal, I think it should be a cross-team effort to nail it down. I would like to avoid this. We get feedback@ email and questions about bug trackers because Launchpad hides bug tracker registration and does not permit the user to set this information. This is also wrong because the email/question should go to the project maintainers, not us. > It's not going to make it easy for users to fix their mistakes, but it > will at least make it easy for them to report them. We have this problem now in bugs and answers. Bugs has a better history so the teams can fix other user's mistakes. Questions is hard since retargeting and assignees are not in history. > Or alternatively, we can start decorating objects with > "just_an_import=True" and allowing changes by anyone with sufficient > karma/standing on such objects (branches, translation set-ups, project > properties, etc.). I think you are right. I think a good crowd sourcing implementation requires us to complete standing. I wonder if I would need to be scanning Launchpad for spam every day if we had complete standing two years ago. -- __Curtis C. Hovey_________ http://launchpad.net/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
