Community
Participate
Working Groups
Naturally, projects need to be represented in the new project management infrastructure. When viewed by the general population, the project should appear very much as the project summary pages [1] appear today. For an authenticated user who is also a committer on the project, an "edit" button should appear which allows them to directly enter an edit mode that lets allowed modification of all fields. Additional functionality may also appear as links/menues/whatever. Basic information about projects needs to be tracked, including: -- id: full id of the project, including parent segments. Conforms to [\w\-]+(\.[\w\-]+){0,2} e.g. tools.cdt, modeling.emf.cdo name: full name of the project. e.g. Eclipse C/C++ Development Tools, EclipseLink: The Eclipse Persistence Services Project shortName: short or nick-name for the project. e.g. CDT, EclipseLink description: textual description of the project. Generally limited in length to a single paragraph and/or 5-7 bullets. scope: scope of the project. Generally limited to a single paragraph and/or 5-7 bullets. Lifted from the project proposal. proposal: reference to the project proposal. websiteUrl, wikiUrl, gettingStartedUrl, documentationUrl, downloadUrl: various URLs pointing to useful information about the project retentionPolicy: textual description of the project's policy with regard to retaining builds. bugzillaProduct, bugzillaComponent: product and component in Bugzilla isIncubating: true if the project is in incubation, false otherwise (i.e the project is mature). isActive: true if the project is active. This value is set to false if the project is still in the provisioning stage (i.e. the creation process has not yet been completed), or the project is archived following a termination review. parent, subproject: reference to parent project and zero or more subprojects. releases: A collection of project releases. Releases are themselves fairly involved objects with lots of fields represented (see Bug 363524) reviews: A collection of reviews undertaken by the the project. I will open separate bugs to discuss reviews in greater detail. members: references to the project members, including their relationship to the project (e.g. committer, project lead, PMC lead/member) and timing of the relationship (start/end dates). I will open a separate bug to discuss this in greater detail. -- Those individuals with edit ability are able to edit most details of the project, including such things as the project scope. There is implicit trust that committers understand that modifications to the description/scope fields (for example) should be limited so that the meaning is not significantly altered. i.e. you can't just change the scope of a project without undergoing a Restructuring review, but you can wordsmith a bit to make the meaning more clear. The id, isIncubating, and isActive fields are editable only by EF staff. Per the EDP, committers can only be added via election. I'll open a bug to discuss how that will manifest in this infrastructure. Information concerning the nature and purpose of each field (including examples and links to further reading where necessary) will be included with editable fields. In the spirit of it being sometimes easier to simply fish than to teach project members to fish, EF staff will be granted broad ability to make changes to all project information. Changes to project fields are to be tracked (identity of individual, date of change, and diff where possible). [1] http://www.eclipse.org/projects/project.php?id=tools.cdt
> For an authenticated user who is > also a committer on the project, an "edit" button should appear I think most of the fields listed in comment 0 should only be allowed for editing by project lead(s) and PMC.
(In reply to comment #1) > I think most of the fields listed in comment 0 should only be allowed for > editing by project lead(s) and PMC. I disagree. My starting position is that I trust committers to do the right thing. Sometimes mistakes are made, so I tend to work in a "trust but verify" sort of mode. Unless there is some very compelling reason to do otherwise, I would rather not artificially restrict committers from doing what they believe they need to do.
(In reply to comment #2) > (In reply to comment #1) > > I think most of the fields listed in comment 0 should only be allowed for > > editing by project lead(s) and PMC. > > I disagree. My starting position is that I trust committers to do the right > thing. Sometimes mistakes are made, so I tend to work in a "trust but verify" > sort of mode. > > Unless there is some very compelling reason to do otherwise, I would rather not > artificially restrict committers from doing what they believe they need to do. Things like the project name or description, or whether a project participates in the release train should not be changed by a committer. Also bugzilla targets and versions. Especially, if failures can't be corrected like it's currently the case with the portal.
(In reply to comment #3) > > Things like the project name or description, or whether a project participates > in the release train should not be changed by a committer. Also bugzilla > targets and versions. Especially, if failures can't be corrected like it's > currently the case with the portal. Are you concerned about malicious intent or mistakes? FWIW, Drupal supports revision management. We're going to make it automagic, so any and all changes can be rolled back.
(In reply to comment #4) > (In reply to comment #3) > > > > Things like the project name or description, or whether a project participates > > in the release train should not be changed by a committer. Also bugzilla > > targets and versions. Especially, if failures can't be corrected like it's > > currently the case with the portal. > > Are you concerned about malicious intent or mistakes? > > FWIW, Drupal supports revision management. We're going to make it automagic, so > any and all changes can be rolled back. Knowing the portal I'm worried about - not knowing who made the change - not being able to fix the change - not being notified about changes If all that works, then I don't need the restriction :-)
(In reply to comment #5) > Knowing the portal I'm worried about > - not knowing who made the change > - not being able to fix the change > - not being notified about changes > > If all that works, then I don't need the restriction :-) The first two have always been in plan. That last one is a nice addition.
(In reply to comment #6) > (In reply to comment #5) > > Knowing the portal I'm worried about > > - not knowing who made the change > > - not being able to fix the change > > - not being notified about changes > > > > If all that works, then I don't need the restriction :-) > > The first two have always been in plan. That last one is a nice addition. Well, if a committer can e.g. change the project lead without anyone being notified, then I think this is just wrong.
If possible I'd prefer we change the title of this bug. In place editing to me means that you'd be able to edit the items directly on the listing page, one field at a time. While this is technically possible in Drupal, it would make any kind of revisioning difficult. Overall I think what were driving for here is to make it less of a burden to edit these pages (see current portal). Currently i just show an edit tab that presents a nice overlayed form to the user should they have the appropriate permissions. > Well, if a committer can e.g. change the project lead without anyone being > notified, then I think this is just wrong. Project to user relationships will not be changeable by a committer, this is a function that would belong to an EMO staff role.
(In reply to comment #8) > If possible I'd prefer we change the title of this bug. In place editing to me > means that you'd be able to edit the items directly on the listing page, one > field at a time. While this is technically possible in Drupal, it would make > any kind of revisioning difficult. That was not what was intended. > Overall I think what were driving for here is to make it less of a burden to > edit these pages (see current portal). Currently i just show an edit tab that > presents a nice overlayed form to the user should they have the appropriate > permissions. +1 > > Well, if a committer can e.g. change the project lead without anyone being > > notified, then I think this is just wrong. > > Project to user relationships will not be changeable by a committer, this is a > function that would belong to an EMO staff role. One of the features we'll include is the ability to elect project leads.
I took a peek at http://projects.eclipse.org and found several problems: The icon is wrong. I'm used to see the official Eclipse icon on pages that come from eclipse.org. The new icon causes confusion. The project name is taken from the portal. This leads to meaningless names like "UI" because so far the projects are listed hierarchically: http://www.eclipse.org/projects/listofprojects.php. We have to ask the project leads to either change it before the migration or let them change it later (oops, see next item). I (PMC member) cannot change the project name - it is disabled. The bugzilla status is confusing: the first thing that jumped to my eyes was the many zeroes and I thought, hey did we not fix things? Please use "N/A" or "-" to indicate impossible values instead of zeroes. It looks like the data is not live i.e. if I change them in the portal, they are not reflected on http://projects.eclipse.org. This is fine if the portal is dropped but not otherwise. Many of my roles (see http://projects.eclipse.org/users/dmegert) have a wrong 'Since' date (2012/04/03). This should be fixed as it gives a wrong picture of seniority to people who visit my page. Having said all that: I really like how the pages look and the information they present. Definitely nicer than the portal!
(In reply to comment #10) > The project name is taken from the portal. This leads to meaningless names > like > "UI" because so far the projects are listed hierarchically: > http://www.eclipse.org/projects/listofprojects.php. We have to ask the > project > leads to either change it before the migration or let them change it later > (oops, see next item). This is not as bad as I thought. On the normal pages this isn't an issue, as there hierarchy (sub project) is also visible. I encountered it on the personal information page (http://projects.eclipse.org/users/dmegert). Maybe this page also needs to present the project in their hierarchy.
(In reply to comment #10) > I took a peek at http://projects.eclipse.org and found several problems: > > The icon is wrong. I'm used to see the official Eclipse icon on pages that come > from eclipse.org. The new icon causes confusion. I've updated the favicon.ico file to be the standard eclipse icon. This should appear in the next push. > > The project name is taken from the portal. This leads to meaningless names like > "UI" because so far the projects are listed hierarchically: > http://www.eclipse.org/projects/listofprojects.php. We have to ask the project > leads to either change it before the migration or let them change it later > (oops, see next item). > As you later discovered we are trying our best to place projects into breadcrumbs and the like to make sure we have useful information to pair the project title with, that said i'll look at the roles table and see how i can make that info more relevant. > I (PMC member) cannot change the project name - it is disabled. > I disabled changing the title a while ago for some reason, let me bat this around with Wayne and i'll report back. > The bugzilla status is confusing: the first thing that jumped to my eyes was > the many zeroes and I thought, hey did we not fix things? Please use "N/A" or > "-" to indicate impossible values instead of zeroes. I'll let Wayne chime in on this one, i'm indifferent. > > It looks like the data is not live i.e. if I change them in the portal, they > are not reflected on http://projects.eclipse.org. This is fine if the portal is > dropped but not otherwise. The portal will be dropped at some point and at that time we will sync the data so it is consistent. projects.eclipse.org is currently a sandbox and the data there is likely to be overwritten. > > Many of my roles (see http://projects.eclipse.org/users/dmegert) have a wrong > 'Since' date (2012/04/03). This should be fixed as it gives a wrong picture of > seniority to people who visit my page. > > This is definetly a bug, i'll look into this today. > Having said all that: I really like how the pages look and the information they > present. Definitely nicer than the portal! Thanks!
(In reply to comment #12) > (In reply to comment #10) ... > > The project name is taken from the portal. This leads to meaningless names > like > > "UI" because so far the projects are listed hierarchically: > > http://www.eclipse.org/projects/listofprojects.php. We have to ask the project > > leads to either change it before the migration or let them change it later > > (oops, see next item). > > > > As you later discovered we are trying our best to place projects into > breadcrumbs and the like to make sure we have useful information to pair the > project title with, that said i'll look at the roles table and see how i can > make that info more relevant. This is one of the main drivers behind this effort: to make it easier for project leads and committers to provide relevant and up-to-date information. You are able to change this information in the portal today, and it's reflected in a number of different places, including the project information pages: http://www.eclipse.org/projects/project.php?id=eclipse.platform.ui In fact, this page serves as a model for the new stuff we're building, but with the added benefit of making it easier to modify the values that are displayed. > > I (PMC member) cannot change the project name - it is disabled. > > > > I disabled changing the title a while ago for some reason, let me bat this > around with Wayne and i'll report back. This should be enabled. See Bug 375943. > > The bugzilla status is confusing: the first thing that jumped to my eyes was > > the many zeroes and I thought, hey did we not fix things? Please use "N/A" or > > "-" to indicate impossible values instead of zeroes. > > I'll let Wayne chime in on this one, i'm indifferent. Bug 375944. > > > > It looks like the data is not live i.e. if I change them in the portal, they > > are not reflected on http://projects.eclipse.org. This is fine if the portal > is > > dropped but not otherwise. > > The portal will be dropped at some point and at that time we will sync the data > so it is consistent. projects.eclipse.org is currently a sandbox and the data > there is likely to be overwritten. There is no live synch between the Portal and the new implementation. The new implementation will start from a snapshot of the data from the current system sometime in early July. > > > > Many of my roles (see http://projects.eclipse.org/users/dmegert) have a wrong > > 'Since' date (2012/04/03). This should be fixed as it gives a wrong picture of > > seniority to people who visit my page. > > > > > > This is definetly a bug, i'll look into this today. Nathan, open a bug to track this. > > Having said all that: I really like how the pages look and the information > they > > present. Definitely nicer than the portal! > > Thanks!
I'm going to declare victory on this bug on the basis that projects are well-represented in the PMI. We're not 100% yet, but we can deal with the outstanding issues with other bugs (many of which are currently blocked by this bug). Note that I've reorganized a bugs that had previously been listed as dependencies into blockers. I think we got this the wrong way around the first time through.
