Talk:MDT/Papyrus-Proposal

• Precise the content of the initial contribution
• Refine the component architecture
• Choose an organization and a leader: a kind of PMC + one leader ? Due to the relative investment of the developers (to be detailed ?), I suggest to choose Sébastien to lead the component, with the other candidates in this committee.
• Detail the planning
• Change "project" into "component"

• [Kenn] : I’ll take a closer look at the proposal soon, but in the meantime note that we need to more consistently use “component” instead of “project”, and that we should identify one lead for this component (instead of two or three).

• [raphaël] : in fact we need 5 components and two levels.

Papyrus is the UML tool and the final deliverable for UML end users (higl level component with a dedicated roadmap) Papyrus is composed of several lower-level components (each of them having a roadmap):

 a) backbone (the diagram container) with an API to integrate diagrams into, 
 b) MTD diagram adaptor : a layer on top of MDT diagrams to make them conform to the backbone API
 c) other UML diagrams outside of MDT : contributions of other diagrams that will be developed directly in Papyrus Eclipse component
 d) facilities (EMFCompare, outline, properties...) : all things to integrate to have full-featured tool
 e) XMIDI reference implementation, with import and export commands.

• [Kenn] These seem more like features than components. There should be one roadmap into which the plans for each of these features will fit...

• [raphaël] in that case those would be really huge features ;-) the backbone, for instance, will provide multi-editor layout, multi-diagrams model, collaborative work support...

The idea of presenting those "large features" as components is based on two ideas : parallel work and modularity. By creating them as components we ensure that there be one leader and one roadmap for each, in addition to an integration planning to reach the global tool level. With such a structure, it gives immediately the rules of efficient parallel work (different teams can work on different components at the same time when interfaces are clearly defined) and promotes modularity through potential reuse of each group of features.

• [Kenn] OK, that makes sense, then. There are no restrictions on how the functionality/code within a project/component is organized - we should impose whatever structure makes sense. Currently, only projects and sub-projects are officially recognized at Eclipse (components are "second class" entities), but if/when the proposed changes to the development process are approved (see http://www.eclipse.org/projects/dev_process/development_process.php#), nesting of projects (each with its own leadership and associated list of committers) can take place at any level...