Greg:
Thanks very much that you have already make a clear structure of
document-list. That ‘s really cool.
For the questions:
? Should we organize ourselves by topic, by project, or some other structure?
I suggest organize ourselves by project. That means at least one or two person
follow each project to release the content (maybe not all by themselves also by
other person in that project).
I think we first need to confirm the final list for R1, and I think not too
much, setup, using ONAP and developing documents as you list will be more
important.
Besides that, we need to select some topics to deliver some PDF for R1. I think
at least we need a RN, a user guide, a developer guide, an API reference and a
trouble shooting guilde.
? Is our team responsible for overseeing every topic (insuring documentation
is accurate, timely and comprehensive)? I would think for Technical topics
absolutely yes, but what about Project Mgt and Community topics
I think that’s impossible to oversee everything especially for mgt and
community topics. What we need is just build a system like wiki to engage most
our developers and architects to contribute enough content. And as an open
platform, wiki could be very fast to fix mistake and release correct topic at
last. The history of each issue should be very important for everyone. So I
suggest to use markdown as the documents developing language. Because it simple
for everyone. I will introduce it at the next meeting.
? Will every topic have documentation updates driven by a scheduled release?
If not how should we handle
We need to confirm what changes for each topic as a new release. So maybe we
should first complete organization task.
? Are there topics and/or projects that are missing? I didn’t include the
list of proposed projects �C they may help fill in some gaps
For the missing I just notice that you have not mention about the trouble
shooting topic. Maybe some demo or record for operation are needed too.
发件人: GLOVER, GREG L [mailto:[email protected]]
发送时间: 2017年6月21日 4:36
收件人: BENNETT, RICH <[email protected]>; HU, JUN NICOLAS <[email protected]>;
[email protected]; GLOVER, GREG L <[email protected]>; SCAGGS, KEVIN
<[email protected]>; WRIGHT, STEVEN A <[email protected]>; Yangliu (E)
<[email protected]>; [email protected];
[email protected]; [email protected]
抄送: [email protected]; ANDERSON, ANDREA <[email protected]>; BUJA,
JOHN <[email protected]>; FRAZER, BERNARD <[email protected]>;
LOEWEN, SHAWN <[email protected]>; [email protected];
[email protected]
主题: ONAP Documentation scope
All,
Attached is a first cut at mapping the ONAP topics (Developer wiki) to the 24
approved projects. Note the following:
* The topics are listed down the side and are separated into three tabs:
Technical, Project Mgt and Community
* The projects are listed across the top (project descriptions are in the
row below)
* The topics and projects are highlighted in red if they have at least one
intersection (“X”). Note there are a few of each that aren’t highlighted.
Some questions we’ll need to answer:
? Should we organize ourselves by topic, by project, or some other structure?
? Is our team responsible for overseeing every topic (insuring documentation
is accurate, timely and comprehensive)? I would think for Technical topics
absolutely yes, but what about Project Mgt and Community topics
? Will every topic have documentation updates driven by a scheduled release?
If not how should we handle
? Are there topics and/or projects that are missing? I didn’t include the
list of proposed projects �C they may help fill in some gaps
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
