Community
Participate
Working Groups
The Mylyn project is proposed for restructuring: http://www.eclipse.org/project-slides/mylyn-restructuring-review.html
Uh... I'm a bit puzzled... no one commenting ? No interest from the community :-/ I think not... probably everyone lagging ?
Olivier: We discussed this regularly on the weekly Mylyn call, hence the lack of comments from committers. To participate in those calls see: http://wiki.eclipse.org/Mylyn_Meetings We have until April 7th to consume comments, since that's when the restructuring gets its formal review. Comments can also be provided during the review scheduled for that day.
Hmm... maybe a quick comment on process if the community enlarges... My understanding is that some of the meetings happen on conference calls ? Maybe some piece of advice on a methodological level : if you open to more partners including potential (volunteer) contributors that have different online presence constraints (language, timezone, etc.), then more written communication on asynchronous channels may be required (mailing lists and IRC mainly). Then I'm not sure this is exactly the current plan to live like Open Communities in Open Source projects ;) Just my 2 cents of non crucial points... hoping that other more important stakeholders won't be shy and discuss in the open ;)
(In reply to comment #3) > My understanding is that some of the meetings happen on conference calls ? > > Maybe some piece of advice on a methodological level : if you open to more > partners including potential (volunteer) contributors that have different online > presence constraints (language, timezone, etc.), then more written communication > on asynchronous channels may be required (mailing lists and IRC mainly). All meeting discussions happen on conference calls that anyone can participate in. Participation instructions are at: http://wiki.eclipse.org/Mylyn_Meetings Time zones are always a challenge. We are always open to altering the meeting time to enable more participation, but we are limited to a single call slot per week, so we have to find a suitable compromise, and rely on asynchrounous channels beyond that.
With regard to timezones, the normal Mylyn time is 6pm local time when I normally go home at latest. But in Vancouver this is 9am, so earlier is no really possible. So how about rotating week days? Tuesday would fit for me perfectly.
Mik, is this the right moment to consider having the Industrial SQL Connector allowing connection to any SQL database as a standard component? See bug 184532
At EclipseCon, we held the "Mylyn is Falling Apart" BOF. At the BOF, we were able to gather some information from integrators on what they would like to see from the restructuring and some of the sub-projects. Here are the items that were discussed: h4. Packaging: * All commons bundles consumable via features * Separate out the team repositories view and some API to commons (make it consumable by SCM, etc) h4. General * Move provisional packages to API for commons * Less static methods in WebUtil * Adding connector specific language (i.e. changesets vs changelists) h4. Context: * Branch handling with tasks and context with SCM support (what branches have what code) * EMF bridge? h4. Build: * Improve connector idea to support non-task connectors but use a similar framework * Associate changesets with builds and tasks (SCM integration) * Builds tab in the task editor to see builds related to a task (maybe trigger a build as well) h4. Tasks: * Task editor layout customization * User controlled layout customizations h4. SCM: * Changeset resolver given a task * Api for review support * Support for non-local changesets and operations (off of the UI thread) * Create changesets in SCM connectors smartly (only create as needed)
(In reply to comment #6) > Mik, > > is this the right moment to consider having the Industrial SQL Connector > allowing connection to any SQL database as a standard component? See bug 184532 Maarten: Yes, I think it is! Thanks for the reminder and sorry for the slow reply. Are you still interested in pushing forward with that effort? If so, I will incorporate it into a wiki page describing the project, and we can iterate. Shawn: Great summary, will add to the wiki summary and post back on this bug when done.
What's the outcome of the restructuring review period, finally ?
We had a successful review, but in the last week there was additional interest in participaiton around the project. I am collecting that now, will put up a wiki page of the summary today or tomorrow, and link that here.
Here is the wiki page describing the planned restructuring: http://wiki.eclipse.org/Mylyn/Restructuring Please provide any input here, as we will hold off on provisioning the new projects until we have had time to refine and gather more input.
-----Original Message----- From: Mik Kersten [mailto:mik@tasktop.com] Sent: May-25-10 10:52 AM To: 'mike.milinkovich@eclipse.org'; 'Chris Aniszczyk'; 'Wayne Beaton' Cc: 'Janet Campbell' Subject: RE: Mylyn Top Level Project Charter Putting it on the agenda, presenting it at the June meeting, and then having an electronic vote sounds good to me. Assuming that Wayne gets over the Flyers. We have one open discussion item, which is the name and branding of the top-level project. To summarize, in the fall Ian Skerrett and I converged on "Mylyn" for brand awareness reasons and lack of a good descriptive name. Since that time analysts and press have been using Mylyn as the name of the broad Agile/Task/ALM project, not just the task-focused interface. More recently Mike stated that a top-level projects do not have branding names, and that there needs to be room for branding the subprojects. After that I had considerable discussion with Chris, Wayne, and the Mylyn committers. Here's where we got to. We think that we need some kind of brand for the top level project, and have descriptive "Framework Projects" under that, one for each of the ALM categories (eg, Tasks, Builds, Reviews). These are consumed by adopters/integrators/ISVs. We need separate branding for each of the "Tools Projects", which are consumed by developers. These are all of the form "Eclipse/Mylyn integration for <ALM server or tool" (eg, EGit, Bugzilla Connector, Hudson Connector, WikiText). In other words, they need their own brand which refers to the thing they're integrating with. They need to retain an independent user community and web site who uses that tool, even though they all fit under one of the Framework Projects (eg, EGit under SCM). We made this distinction and branding clear under: http://wiki.eclipse.org/Mylyn/Charter#Scope This still leaves us with the need to have the top level thing branded, and to have the term "Mylyn" bind to something. In the minds of people outside of the Eclipse bubble that term is already bound to what we are proposing as the TLP. A good example of this is the recent Forrester podcast, which is definitely worth a quick listen in terms of a summary of the industry understanding of "Mylyn", its positioning, and how the focus on using tasks to unify ALM makes it a fundamentally different approach than previous efforts like ALF: http://bit.ly/9CEYDh (skip to 4min 45s). We propose a compromise, using both a descriptive name and continuing to use the "Mylyn" short/nickname. We realize that this the first instance of this kind of branding, but projects like BIRT, WTP and Modeling are successful brands, and the success of the TLP effort is related to the success of this brand (blame Ian for recommending marketing books to me, which have definitely affected my thinking about OSS diffusion of innovation). Also, all of those who have expressed interest in making their projects sub-projects of this TLP want to be part of the Mylyn brand, and Tasktop has long ago decided that the dilution and diversification of this brand is a good thing for all. We want to keep the term "Management" out of it because it turns off developers who dominate our community. The two candidates that we have are "Mylyn - Application Lifecycle Tools (MALT)" and "Mylyn - Task and Application Lifecycle Tools". The first is nicer, while the second is more descriptive in terms of how key the tasks angle is in tying the stack together. Thoughts? Mik
(In reply to comment #12) > -----Original Message----- > From: Mik Kersten [mailto:mik@tasktop.com] > Sent: May-25-10 10:52 AM > To: 'mike.milinkovich@eclipse.org'; 'Chris Aniszczyk'; 'Wayne Beaton' > Cc: 'Janet Campbell' > Subject: RE: Mylyn Top Level Project Charter > > Putting it on the agenda, presenting it at the June meeting, and then having an > electronic vote sounds good to me. Assuming that Wayne gets over the Flyers. > > We have one open discussion item, which is the name and branding of the > top-level project. To summarize, in the fall Ian Skerrett and I converged on > "Mylyn" for brand awareness reasons and lack of a good descriptive name. Since > that time analysts and press have been using Mylyn as the name of the broad > Agile/Task/ALM project, not just the task-focused interface. More recently > Mike stated that a top-level projects do not have branding names, and that > there needs to be room for branding the subprojects. After that I had > considerable discussion with Chris, Wayne, and the Mylyn committers. Here's > where we got to. > > We think that we need some kind of brand for the top level project, and have > descriptive "Framework Projects" under that, one for each of the ALM categories > (eg, Tasks, Builds, Reviews). These are consumed by adopters/integrators/ISVs. > > We need separate branding for each of the "Tools Projects", which are consumed > by developers. These are all of the form "Eclipse/Mylyn integration for <ALM > server or tool" (eg, EGit, Bugzilla Connector, Hudson Connector, WikiText). In > other words, they need their own brand which refers to the thing they're > integrating with. They need to retain an independent user community and web > site who uses that tool, even though they all fit under one of the Framework > Projects (eg, EGit under SCM). > > We made this distinction and branding clear under: > http://wiki.eclipse.org/Mylyn/Charter#Scope > > This still leaves us with the need to have the top level thing branded, and to > have the term "Mylyn" bind to something. In the minds of people outside of the > Eclipse bubble that term is already bound to what we are proposing as the TLP. > A good example of this is the recent Forrester podcast, which is definitely > worth a quick listen in terms of a summary of the industry understanding of > "Mylyn", its positioning, and how the focus on using tasks to unify ALM makes > it a fundamentally different approach than previous efforts like ALF: > http://bit.ly/9CEYDh (skip to 4min 45s). > > We propose a compromise, using both a descriptive name and continuing to use > the "Mylyn" short/nickname. We realize that this the first instance of this > kind of branding, but projects like BIRT, WTP and Modeling are successful > brands, and the success of the TLP effort is related to the success of this > brand (blame Ian for recommending marketing books to me, which have definitely > affected my thinking about OSS diffusion of innovation). Also, all of those > who have expressed interest in making their projects sub-projects of this TLP > want to be part of the Mylyn brand, and Tasktop has long ago decided that the > dilution and diversification of this brand is a good thing for all. I definitely support this. > We want to keep the term "Management" out of it because it turns off developers > who dominate our community. The two candidates that we have are "Mylyn - > Application Lifecycle Tools (MALT)" and "Mylyn - Task and Application Lifecycle > Tools". The first is nicer, while the second is more descriptive in terms of > how key the tasks angle is in tying the stack together. > > Thoughts? I like the first option. I think regardless of the option we choose, people will refer to things as Mylyn, it's just shorter. Another thing to think about is that if we chose the first option, people could refer to the project as Eclipse MALT. Would that be a bad thing?
(In reply to comment #13) > I like the first option. I think regardless of the option we choose, people will > refer to things as Mylyn, it's just shorter. Another thing to think about is > that if we chose the first option, people could refer to the project as Eclipse > MALT. Would that be a bad thing? I have to say that I like MALT too, and M-ALT is also neat given how much Mylyn's UI has ended up using the Alt modifier due to Platform having taken all the good Ctrl based modifiers :)
(In reply to comment #14) > (In reply to comment #13) > > [...] people could refer to the project as Eclipse > > MALT. Would that be a bad thing? > > I have to say that I like MALT too, and M-ALT is also neat given how much > Mylyn's UI has ended up using the Alt modifier due to Platform having taken all > the good Ctrl based modifiers :) And Steve Northover unfalteringly resisted to add the Meta modifier (abbreviated usually as "M-") to the platform... Sorry, could not resist :-)
As discussed on today's call, one thing that is currently not explicit in http://wiki.eclipse.org/Mylyn/Charter is a notion of lightweight or piggy-back projects that have their release reviews, downloads, new & noteworthy, plan, etc. rolled-up in the top-level project. I am thinking of the Trac Connector for instance that is in itself not big enough to warrant the full management overhead but it still makes sense to have a separate set of committers.
This sounds reasonable to me for smaller components that track very closely with their framework project, like the Mylyn/Context/Java sub-project. However, I think that everything that has an independent community, eg, Bugzilla, Trac, Git, may deserve it's own project plan, even if that project plan is small. In general, I think that the good examples for us to figure out here are WTP and Modeling, which take different appraoches afaik, with the former being more of a unified plan and the latter leaning to independent plans. Either way, I think we need some independence so that sub-projects like Reviews can run at their own pace. Ed: How do you manage this tradeoff of providing people with one plan for a top-level project that they can view at a glance, vs. a large number of independent plans?
Based on discussions on the mailing list and conference calls we have decided to create the projects listed in the restructuring proposal as sub-projects of the new Mylyn top-level project. Each project will host a framework component and one or more reference implementations. In the future we may consider splitting out components as sub- or sub-sub-project. Here are some thoughts for criteria that could qualify a component to be split out as a separate project: * A component requires incubation status (e.g. for parallel IP) but the framework project has already matured. * The committer set of the component is not a subset of the committer set of the framework project. * A component wants to release more frequently than its framework project, i.e. it follows it's own project plan. * A component publishes its own APIs and its scope and community are significant that it requires its separate management structure such as a Bugzilla product, news group etc.
Thanks everyone for the input on the restructuring. Mylyn is now a top-level project (bug 328383) and provisioning of sub-projects is mostly complete (bug 328393). Top-level project charter: http://wiki.eclipse.org/Mylyn/Charter Sub-project structure: http://wiki.eclipse.org/Mylyn/Restructuring Indigo participation: Bug 317543 Projects: * Mylyn: http://eclipse.org/projects/project_summary.php?projectid=mylyn * Mylyn Builds: http://eclipse.org/projects/project_summary.php?projectid=mylyn.builds * Mylyn Commons: http://eclipse.org/projects/project_summary.php?projectid=mylyn.commons * Mylyn Docs: http://eclipse.org/projects/project_summary.php?projectid=mylyn.docs * Mylyn Context: http://eclipse.org/projects/project_summary.php?projectid=mylyn.context * Mylyn Incubator: http://eclipse.org/projects/project_summary.php?projectid=mylyn.incubator * Mylyn Reviews: http://eclipse.org/projects/project_summary.php?projectid=mylyn.reviews * Mylyn Tasks: http://eclipse.org/projects/project_summary.php?projectid=mylyn.tasks * Mylyn Versions: http://eclipse.org/projects/project_summary.php?projectid=mylyn.versions
Great work Steffen!
