Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Tools PMC Meeting 2010-04-28
Time: 2:00 PM Eastern
Conference number: North America 1 866-842-3549, Ottawa 613-787-5018, Passcode: 6046633
- If passcode is not recognized. After the third failure, you will be transferred to an operator who will ask for the conference ID (6046633), sponsoring company (IBM) and meeting organizer (Anthony Hunter).
- Pressing *0 will bring you directly to an operator.
Attendees
- Doug Schaefer, David Williams, John Duimovich
Agenda/Notes
[This are my (davidw) rough notes from the meeting ... so there may be some inaccuracies or omissions ... John or Doug feel free to correct.]
- We discussed issues with purpose, operation, and reputation of Tools TLP.
- Its perceived by some that the Tools PMC is not very active (true enough), but we also thought we are probably more "functional" than some ... does this mean there is a larger problem at Eclipse, where the "Top Level Project" is not working as expected? It is for some (Eclipse, Web Tools) but less sure about others.
- One problem in Tools PMC: none of us have time (with other job priorities) to spend much time on "high level" activities outside our occasional meetings.
- What would those high level activities be? Learning about projects, in enough detail to know what they are doing, if doing it well, if there's other groups they could collaborate with. Another might be to do more "monitoring" ... keep up with projects dev lists, blogs, number of bugs open and resolved, number of junit tests run, meeting schedules, sim. rel. criteria, etc.
- So, if we don't have time to do these things, is our first responsibility to find time? Or find replacements for ourselves that would have time and interest?
- It was felt, (I think by all of us) that bringing "outsiders" to the PMC would probably be the wrong thing to do. It should be people that have ties to at least one project in Tools.
- We did not feel that Arch. Council advice would be constructive, and that discussions among general committers in council calls, or in Bugzilla could actually be harmful, as it might perpetuate misunderstandings about how PMCs and management in general works.
- For example, its pretty clear creating some organization by itself would not solve anything. Occasionally, once a problem is understood, a "re-org" might be part of the solution to the problem. For example, perhaps some groups are not communicating enough. Then a new organization might be one way to encourage more communication ... but even then certainly would not be the only solution and would be not guaranteed to work automatically).
- In some discussions we've heard about (and maybe we heard wrong) there seemed to be some "magical thinking" that if a certain group was formed, such as a "Language Top Level Project", then that would some how cause everything about language support to become easier to use, more integrated, more common, etc. That misses the point that in fact what's needed is for someone to invest the time (and money) to have developers do all that work. The organization wouldn't do it. So, to overly drive this point in ground, if some people decided they wanted to have some common tools for language support, then it might help if they were in the same project ... but, again, not necessary nor sufficient, but maybe helpful.
- We think that if/when a broader discussion needs to happen, it should be PMC-to-PMC, not a "community discussion".
- We briefly made note that we should discuss if we should approach some or all current Tools PLs to join PMC, but didn't get very far due to lack of time. Would they want to? What are implications? What would their new responsibilities be? What problem would this be solving?
- For one thing, it might help "groom" people to eventually be senior PMC members, as other PMC members have to leave. Might also make it more apparent who's active and who's not. And, if not active, that'd be an indication (another data point) that the project was not living up to Eclipse standards and should be terminated.
- Some other ideas bantered about: On the (rumored) informal proposal that Tools and Technology merge ... this seemed to be going in the wrong direction ... taking two large projects whose PMCs don't have enough time, making the TLP bigger, the PMC probably smaller ... and would have even less time. And even less "common ground" between projects. No economy of scale.
- There was one discussion that the more tool-like tech. projects come to Tools (two are already in the queue) and perhaps the other long term incubating-no-interest-to-graduate projects in Technology either leave (terminate) or go to Eclipse Labs (if/when it happens).
- Another discussion involved the other direction. Perhaps a "Language TLP" is too abstract, but perhaps an "IDE TLP" would be a concept that many people would be interested in rallying around, and work on. And it might provide a good balance or counter point to the current focus on "runtimes". This direction, if goes anywhere, would involve some blending of IDE projects from Eclipse and some IDE projects from Tools.
- No actions or plans were made ... other than I volunteered to write up these notes while John went fishing :) ... but we did want to keep the momentum and meeting in two weeks, instead of our usual 4th Friday.
Next Meeting
We didn't discuss details, but think we should assume Wed., 5/12 2 PM Eastern, (same phone) unless we decide otherwise. [btw, I could not update the google calandar]
Calendar