| I would think that, since this is under the “Developer” page group, it should first be divided into sections that would appeal to designers. I used the term “features” in the Overview, which is probably wrong as it is more of a product management term. You could call those components or functions, or something else, but they would be things like:
- User interface/experience
- Language (UML-RT)
- Code Generation
- Runtime service library
- Validation
- Import
- etc.
These could then be refined at the next level into more specific aspects (or not).
Under each of these, you could then have another level with things such as:
- Releases
- Dead ends
- (Failed experiments)
I’m of two minds as to whether “deprecated” should be some indication for each note or whether a new (sub-) section should be created for these. I like the former because it keeps the history of where the “thinking” occurred - and potential traceability to what replaced them - vs. keeping, for example, the releases clean with what was actually implemented in them.
Just a thought. This is a development section of the wiki and you should set something up that would meet your needs.
Regards,
Charles Rivet
Senior Product Manager, Papyrus-RT product lead
Ok, I can move the codegen docs there, but I think we may need some agreement about the structure of the page.
It is divided in "Overview" and "<Version> Release". My question is, if we are going to have documents covering
1) version-specific notes 2) notes describing obsolete or deprecated designs ("what was") 3) notes describing future or proposed designs ("what will/should be") 4) notes describing the current state ("what is") 5) notes applicable to all, or more than one release ("what was and is and possibly will be")
Should we divide the page in sections according to such classification, or other?
It would seem odd to me to just dump the current codegen docs in the page without clarifying whether they represent the current state, or a past state or a proposal.
I think it would be preferable to make the nature of the notes explicit.
-- Ernesto
+1 All information is good, whether implemented or abandoned.
In case you didn’t know, The Eclipse implementation of MediaWiki allows you to easily create highlighted notes by using the patter: {{Note | NoteKind | note text }} (I have a TextExpander snippet for this… if anyone is interested). It does not, however, support all note types from MediaWiki…
Hi, I do agree with Christian on letting all information displayed, even if they did not reach a release. With a small indication telling that it did not make into the release. Regards, Rémi
------------------------------------------------------- Rémi SCHNEKENBURGER CEA Saclay Nano-INNOV Institut CARNOT CEA LIST
I think this page should include any and all feature design information. Any page that describes abandoned technology or an experiment that ended up not being realized in the product should clearly indicate that, but remains useful to show how the product took shake. So, I’d say, yes, move any codegen documentation into this corner. At least, that’s my own 2¢. On 17 November, 2016 at 14:32:14, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote: Thanks. One thing that is not clear to me, though, is whether the Design Notes should include only the "what should be", i.e. the planned or proposed design(s) (of some part of Papyrus-RT) or whether it should also include the "what is", i.e. the design currently implemented. Also, we do have the later for codegen, but I'm not aware of any design docs for the other components. If the purpose of the page is the later, then we should move the codegen pages there too. I have added the page for design notes, with a link from the (new) Developer page. On 17 November, 2016 at 13:19:34, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote: That moved the "Developer Guide" to "Developer", but there is still no "Design" section or page, is that right? I have completed a reorganization of the wiki. Redirects have been created for all page moves and a note has been added to the main page. If you encounter any problem, please let me know. Charles Rivet
Senior Product Manager, Papyrus-RT product lead I’m fine with this. It’s actually in line with some re-design of the wiki I was thinking about to better fit/align with the “Actors" we had defined for Papyrus-RT: User, Developer, and Toolsmith. I’ll modify the “top-level” “Papyrus-RT” page and start moving things. You should be able to have access to "Papyrus-RT/Developer” before lunch. I’ve got a draft of a design note for the UML-RT implementation in UML (subject of recent discussion around demos) ready in MediaWiki format, just looking for a home on the Papyrus-RT wiki. However, that home doesn’t seem to exist, yet. Or, at least, I can’t see how to navigate to code-level design information from the main Papyrus-RT page. How would we like to organize the design notes that we would like to share? The Papyrus project uses “incoming work” pages per release to collect these notes, but I don’t like that terminology. I was thinking maybe something like Papyrus-RT/Developer/Design/0.9/UML-RT-Implementation
for my particular page. So, a developer corner with a place for design notes, by release, with my feature targeting 0.9. Re-targeting a feature just means renaming the page so that it ends up with the appropriate new breadcrumb. Thoughts? I welcome alternative propositions; my suggestion may be too fussy. Thanks, Christian
|
