Community
Participate
Working Groups
There are three places for GMF's contributor information, and they're not very well linked together: http://www.eclipse.org/modeling/gmf/project-info/team.php http://www.eclipse.org/modeling/gmf/development/contributors.php http://www.eclipse.org/modeling/gmf/development/ipquery.php (one generated IP log for the whole project) Meanwhile, other projects have a different approach: http://www.eclipse.org/modeling/emf/project-info/team.php http://www.eclipse.org/modeling/emf/eclipse-project-ip-log.php (one IP log for the whole project) http://www.eclipse.org/modeling/mdt/project-info/team.php http://www.eclipse.org/modeling/mdt/eclipse-project-ip-log.php (one IP log per component) http://www.eclipse.org/modeling/m2t/project-info/team.php http://www.eclipse.org/modeling/m2t/eclipse-project-ip-log.php (one IP log per component) Also, EMF is debating using the "contributed" keyword (bug 229998) for marking contribs in bugzilla, which it would seem GMF is already doing. We need a consistent workflow for all the projects. Going forward, what would you guys like to do?
I don't understand the point of this bug at all. You're pointing out that we have a pre-picture version of the contributors page? I'll remove it. The IP log we use is generated, and depends on the contributed keyword. If other modeling projects would like to take the approach, that's fine.
(In reply to comment #1) > I don't understand the point of this bug at all. Two points: a) there are two ways to list contributors/committers for GMF; one for others. We should be consistent (but if there's information in your old image-free page that needs to be migrated into the new database-driven approach, let me know.) Also, we should clean up extraneous links to the old page and point to the new one. b) GMF does a better job of specifying IP log data (generated instead of statically defined at the project or component level) than do the other projects. My question was to Ed -- should we move to the generated format? If so I'm guessing we'll have to go back into the old bugs and add 'contributed' keywords. This is just one of those end of the cycle cleanup bugs (along with updating copyrights and licenses (when necessary)) that makes us a model project. :)
I maintain a list of contributors for IP log purposes (those that are not committers) as well. I didn't realize that the database was to be used for this, and I'm not sure I like the idea if it's public access, as there is personal contact information required to be maintained. To me, the picture page replaces the non-picture page, but not sure it is the solution for contributor information required to be maintained for IP purposes. I don't have a problem with eliminating the original contributors page at all, though can't seem to connect to CVS today using extssh. I'd be for everyone using the generated approach and the process we defined for GMF in all of modeling.
(In reply to comment #3) > I maintain a list of contributors for IP log purposes (those that are not > committers) as well. I didn't realize that the database was to be used for > this, and I'm not sure I like the idea if it's public access, as there is > personal contact information required to be maintained. Sorry, I wasn't clear. The photos/emails/committerid/names/roles/company information in the team database is for committers/contributors who want to be listed. (The committerids/emails aren't posted on the website, I just store it because eventually I intend to have all this information merged w/ the Foundation's database and it helps to have that extra data for merging. It makes my job easier when I have to do releng for people and need to cross-ref who's who.) Contact information related to IP log is another issue, and I'm not suggesting that needs to be public, though I might argue that with everything being open and transparent, good process and clean IP means being able to easily find someone without needing to dig up a private internal database. (That's a different can of worms though, and IANAL.) My point was simply that there's a bit of a mismatch between the way that contributor names and contributor IP log data (two separate but related bits of data) are collected. We do some things well, GMF does others better. I opened this bug to get the ball rolling on merging the best of both into one story for all of Modeling. (In reply to Ed) > Do you have the tagging style that you are able to query > in order to produce the log information documented somewhere? > I would imagine, for example, that we'd be able to run a > query that would produce all the entries that should be there > for this release. If you pick any random bug in the IP log, you can see the style we use. It's not automated or generated -- it's entirely by hand right now. https://bugs.eclipse.org/bugs/show_bug.cgi?id=130468#c4 https://bugs.eclipse.org/bugs/show_bug.cgi?id=132360#c4 Many contributions aren't tagged at all: https://bugs.eclipse.org/bugs/show_bug.cgi?id=177645 Regarding how the GMF query works, here's a link to the SQL: http://dev.eclipse.org/viewcvs/index.cgi/www/modeling/includes/ipquery-common.php?root=Eclipse_Website&content-type=text%2Fplain&view=co If I'm not mistaken, we would need to ensure all our contribs are tagged w/ the 'contributed' keyword. Rich: are there other workflow constraints with your approach?
For the sake of argument (and because I found an mdt-ipquery.php in the gmf/development/ folder which only contained uml2tools' mgolubev's info), I've spun off this to test the query for MDT: http://www.eclipse.org/modeling/mdt/project-info/ipquery.php However, it only contains OCL and Uml2 Tools data, suggesting that for the other projects, no one's been using 'contributed' ... yet.
(In reply to comment #4) > Contact information related to IP log is another issue, and I'm not suggesting > that needs to be public, though I might argue that with everything being open > and transparent, good process and clean IP means being able to easily find > someone without needing to dig up a private internal database. (That's a > different can of worms though, and IANAL.) Right, and the Foundation does their best to maintain personal information personal (e.g. address and phone number). I once asked about keeping even contributor information in the Foundation database, but was told it was the Project Lead that was to maintain it. Each release, I send the info to the Foundation. > Rich: are there other workflow constraints with your approach? The process we use is here: http://wiki.eclipse.org/index.php/GMF_Development_Guidelines#Committing_a_Contribution I did some retrofitting after the platform introduced the 'contributed' keyword, as I understand it's how they track contributions as well. Isn't this also discussed in bug 113717 ?
(In reply to comment #5) > For the sake of argument (and because I found an mdt-ipquery.php in the > gmf/development/ folder which only contained uml2tools' mgolubev's info), I've > spun off this to test the query for MDT: > > http://www.eclipse.org/modeling/mdt/project-info/ipquery.php > > However, it only contains OCL and Uml2 Tools data, suggesting that for the > other projects, no one's been using 'contributed' ... yet. Yes, I created this query to help Michael with UML2 Tools, though it was never officially adopted (just forgotten, I guess).
Removed legacy contributors page(s) and updated references to /project-info/team.php Not sure what's left for me to do here, so reassigning.
(In reply to comment #8) > Removed legacy contributors page(s) and updated references to > /project-info/team.php > Not sure what's left for me to do here, so reassigning. Working on a new query for getting the contribs that aren't in patch form (eg., are pasted directly into a bug). Of course much of this will one day be obsoleted by http://www.eclipse.org/projects/ip_log.php?projectid=modeling.emf (bug 220977)
I think we're about as far along here as I can go before being supplanted by Bjorn's work in bug 220977. However, there are a few limitations I can't yet work around in bug 220977 comment 17, which will hopefully be addressed there.
Linked from existing IP log pages.
