Hi, Charles,
Indeed, to me ‘companion’ suggests an additional tool that runs separately, not integrated into Papyrus. I would steer well clear of that! 😉
cW
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.”
Regards,
Charles Rivet
Senior Product Manager, Papyrus-RT product lead
Hi, Sébastien,
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?
Christian
On 3 November, 2016 at 10:43:23, GERARD Sebastien 166342 (sebastien.gerard@xxxxxx) wrote:
Following this discussion (Thanks
Francois ;-) and in order to fix the Papyrus Vocabulary. We have
this notion of product. I see at least two categories of Product I
would like to be able to differentiate. The product that are
selfcontaining such as Papyrus-SysML or Papyrus-RT, and the
products that are to be combined with a Papyrus (Selfcontain)
Product in order to be used as for example Papyrus-DC
(Diff-Compare). In that case, would it be preferable to introduce a
different term such as Papyrus Companion, Papyrus Addin, Papyrus
Component (I do not like this one because component term is already
over used), other?
|
|
|
|
<image001.png@01D235E9.3F46C3A0>
|
|
|
Sébastien Gérard
Head of the LISE labs
CEA Research Director
Papyrus project Leader
(www.eclipse.org/papyrus)
<image002.jpg@01D235E9.3F46C3A0>
Commissariat à l’énergie atomique et aux énergies
alternatives
Institut List | CEA Saclay Nano-INNOV | Bât. 862- PC174
F-91191 Gif-sur-Yvette Cedex
M. +33 6 88 20 00 47
T. +33
1 69 08 58 24
sebastien.gerard@xxxxxx www-list.cea.fr
|
|
|
|
|
<image003.png@01D235E9.3F46C3A0>
|
<image004.png@01D235E9.3F46C3A0> <image005.jpg@01D235E9.3F46C3A0>
|
|
|
|
|
|
|
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?
Séb.
|
|
|
|
<image001.png@01D235E9.3F46C3A0>
|
|
|
Sébastien Gérard
Head of the LISE labs
CEA Research Director
Papyrus project Leader
(www.eclipse.org/papyrus)
<image002.jpg@01D235E9.3F46C3A0>
Commissariat à l’énergie atomique et aux énergies
alternatives
Institut List | CEA Saclay Nano-INNOV | Bât. 862- PC174
F-91191 Gif-sur-Yvette Cedex
M. +33 6 88 20 00 47
T. +33
1 69 08 58 24
sebastien.gerard@xxxxxx www-list.cea.fr
|
|
|
|
|
<image003.png@01D235E9.3F46C3A0>
|
<image004.png@01D235E9.3F46C3A0> <image005.jpg@01D235E9.3F46C3A0>
|
|
|
|
|
|
|
|
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.
[1] https://wiki.polarsys.org/Papyrus_IC/Product_Management
[[SG] >]
Charles
Rivet
Senior Product Manager, Papyrus-RT product lead
Hi,
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".
--
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
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
|
