| Floriant,
Food information, thank you for the link.
Now to find a copy of ISO42010…
/Charles
Hi, To elaborate on the composability of products, I think that a part of the answer to this requirement will be provided by the ongoing work on architecture frameworks. Long story short, this feature will help in partitioning the various Architecture Context (namely the various Architecture Frameworks and Architecture Description Languages) and to switch from one to another. By the way, I would like to encourage anyone to comment this proposal as it will be very structuring for Papyrus in terms of user experience and for Papyrus Product design. The wording we adopted is the ISO42010 one. Note that it is a work document. Feel free to comment using the Discussion tab of this wiki page but please don’t edit directly the page. Best regards. /Florian Thanks Floriant, Some comments inline below. Charles Rivet
Senior Product Manager, Papyrus-RT product lead All your comments are aligned with our current refactoring of Papyrus’ architecture. I like the “Papyrus Extension”. Just as a complement, each of the future Papyrus top and sub projects may release multiple Papyrus Extensions and/or Papyrus Product. Regarding Papyrus Platform, today, we plan to release ‘Papyrus UML’ (or ‘Papyrus for UML’, the name has not been chosen yet) as a Papyrus
<cr> Please note that “Papyrus for UML” is already defined as part of the Papyrus IC Product Management Committee work done during the Ericsson Modeling days. I would like to confirm whether or not we are talking about the same product. From a product Management point of view (as I can’t talk for the Papyrus IC PMC), having a uniform branding strategy is an important factor in marketing the Papyrus (or any, for that matter) product line. As such, I would strongly recommend keeping the “for” for all products, for the reasons stated in a previous response to Sébastien.
</cr>
Product and ‘Papyrus for Toolsmith’ (or what will be chosen) as a Papyrus Product. All the extra plugins in Papyrus main repo will be moved to the appropriate or a new repo (until we have a sub-project for them). In our understanding of Papyrus Product, we expect to provide something downloadable in the form of an RCP (or alike) for it while Papyrus Extensions will be features (according to Eclipse’s wording) that anyone can install from any Papyrus Product. It will be up to each sub project to decide if their Extension is worth the release of a Papyrus Product but we expect that every Papyrus Product will release a corresponding Papyrus Extension.
<cr> </cr>
On this topic, the “Install Papyrus Additional Components” will evolve to reflect this new organization. Also, while Papyrus Team used to maintain the various extras for each release, Papyrus Products and Papyrus Extensions will have their own roadmap. We even think of removing this “Papyrus market place” in favor of a new category (probably named “Papyrus”) in Eclipse marketplace. This would simplify the release of extensions and the maintenance of this marketplace.
<cr> I like this, both from an infrastructure and a marketing point of view.
</cr>
Don’t hesitate to react to my mail. The first proposal of this refactoring will be proposed very soon. That and companions are replaced but the Doctor stays… ;-) Indeed, to me ‘companion’ suggests an additional tool that runs separately, not integrated into Papyrus. I would steer well clear of that! 😉 On 3 November, 2016 at 11:31:48, charles+zeligsoft.com (charles@xxxxxxxxxxxxx) wrote: From a marketing perspective, I like "Papyrus Companion” as it helps with the anthropomorphized approach taken in the blog and on twitter - but that, in itself, is not a valid reason for the selection of the term we use (plus, I can work around it ;-). For the reasons he lists below, I like Christian’s suggestion of "Papyrus Extension.” Charles Rivet
Senior Product Manager, Papyrus-RT product lead I agree that it is important to recognize that some Papyrus Projects (in the Eclipse sense of the organizational structure) are intended to add capabilities to other Papyrus Products (in the sense of deliverable software packages). My own preference for that is the term ‘extension’, because that is exactly what its function is: to augment the feature set of the product by means of addition. The term ‘add-in’ for me suggests something more casual, or at least not as purposefully Papyrus-oriented. So, how about distinguishing ‘Papyrus Product’ and ‘Papyrus Extension’ as two taxonomical labels for Papyrus software packages? On 3 November, 2016 at 10:43:23, GERARD Sebastien 166342 (sebastien.gerard@xxxxxx) wrote: | | | | | Commissariat à l’énergie atomique et aux énergies alternatives Institut List | CEA Saclay Nano-INNOV | Bât. 862- PC174 F-91191 Gif-sur-Yvette Cedex | | | | | | | | | | | |
De : GERARD Sebastien 166342
Envoyé : jeudi 3 novembre 2016 15:34
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : RE: [mdt-papyrus.dev] Toolsmith Good point Charles. If Papyrus succeed to become a top level project it will be product of the Papyrus Product Family. Until that, it will be a kind of sub-project of Papyrus Similarly to SysML. About the naming, we informally agree on having a long name and a short name. The short name should follow this rule (based on EBNF notation): · <Papyrus Product Short Name> = Eclipse Papyrus - <short name postfix> ð Here we should decide if we want restrict the postfix to be an acronym of 2, 3 or more letters? Or be something free including any name? · <Papyrus Product Long Name> = Eclipse Papyrus for <long name postfix> ð Questions: do we really want “for” to be mandatary? Should <long name postfix> be the expansion of the acronym? That mean that <short name postfix> should be an acronym. Other? | | | | | Commissariat à l’énergie atomique et aux énergies alternatives Institut List | CEA Saclay Nano-INNOV | Bât. 862- PC174 F-91191 Gif-sur-Yvette Cedex | | | | | | | | | | | |
Although I like what Maximilian proposes, we need to be careful with the Papyrus branding with regards to the names we use and how we use them. In line with this, my first question is how will this be packaged? Will it be a “Papyrus Additional Component”? Or will it be a full-blown product like those defined by the Papyrus Industry Consortium (Papyrus IC), which has already done some work on consistent naming for the Papyrus product line [1] ? If this is to be the former (Additional Component), then I like Maximilian’s proposal of simply calling it “Papyrus SDK.” If the latter (product in the product line), then I would hope that it could follow the pattern established by the Papyrus IC, that is: - Long name: Papyrus for <<task/domain/user type>>
- Short name: Papyrus-<<short 2-5 characters related to Long Name>>
E.g., “Papyrus for Toolsmiths” as a long name and “Papyrus-TS” as a short name.
In this case, also, it should probably officially become part of the Papyrus IC’s Papyrus product line. Charles Rivet
Senior Product Manager, Papyrus-RT product lead I like "Papyrus for Toolsmiths", what also comes into my mind is the term "SDK" in this context. So another name could be "Papyrus SDK" or even a combination of both "Papyrus SDK for Toolsmiths". Back from EclipseCon Europe, where we had a shared stand with Polarys and Capella with a nice demo of Moka and Designer with Nao, and the talk of Francis on Papyrus IC [0], I would like to know if you have a proposition to name the Papyrus ToolSmith. [1] I have opened a ticket here [2] My pesonla preference ToolSmithS / tss Thanks for your feedback.
Senior Software Architect / General Manager Mobil: +49 176 223 619 18 Phone: +49 89 21 555 30 - 10 Fax: +49 89 21 555 30 - 19 EclipseSource Muenchen GmbH General Managers: Dr. Jonas Helming, Dr. Maximilian Koegel Registered Office: Agnes-Pockels-Bogen 1, 80992 Muenchen, Commercial Register München, HRB 191789
|
