Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release

[David McBride]

Thanks, Bryan.  When I said "quality metrics", I was just using Bin's
language.

I'm still skeptical about the need for documentation-only projects to
participate in a release.  To be clear, it isn't a matter of whether I
think these projects are important.  I also think that there are other ways
for projects to publish their requirements document without tying it to a
release.

However, it's obvious that many in the community think that this is an
important thing to do.  Therefore, if we're going to continue to associate
documentation-only projects with a release, then we need to come up with
some milestones and effective gates that provide some transparency beyond
those involved in the project, itself.

David

On Tue, Sep 6, 2016 at 3:46 PM, SULLIVAN, BRYAN L <bs3...@att.com> wrote:

> David,
>
>
>
> To a point I put into my comments, there is no such thing as a
> “requirements project” in OPNFV anymore. There are projects, and they have
> artifacts. If the artifacts are simply documents, there are quality gates
> that govern them (the gerrit commit review process), and project schedule
> gates as well.
>
>
>
> I’m not sure what you mean as “quality metrics” for code contributed in a
> release, other than gerrit reviews, tests, and project milestones. So I
> would suggest not to push the analogy too far with documents, as the basis
> for holding code up as an example is questionable other than the very same
> things that apply for documents: reviews, tests (to the extent that we test
> documents as suggested on the opnfvdocs project wiki) and milestones.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT
>
>
>
> *From:* David McBride [mailto:dmcbr...@linuxfoundation.org]
> *Sent:* Tuesday, September 06, 2016 1:00 PM
> *To:* HU, BIN
> *Cc:* SULLIVAN, BRYAN L; Georg Kunz; Adi Molkho; Sofia Wallin; Kunzmann,
> Gerald; Daniel Smith; Christopher Price; opnfv-tech-discuss@lists.
> opnfv.org
>
> *Subject:* Re: [opnfv-tech-discuss] How are Documentation/Reference
> Projects Published in C release
>
>
>
> Bin,
>
>
>
> You hit on a key point:  "meets milestones and other quality metrics".
> One reason that I question whether requirements projects should join a
> release is that the requirements projects associated with Colorado
> responded with "N/A" for most or all of their milestone reporting.  That's
> understandable, since the milestones are oriented toward projects that are
> creating or modifying code.  I'm not aware of any quality metrics that they
> have been subjected to.
>
>
>
> So, that raises the question, should requirements projects be tracked in a
> release?  If so, what milestones or other metrics should be used to track
> them?
>
>
>
> David
>
>
>
> On Tue, Sep 6, 2016 at 12:07 PM, HU, BIN <bh5...@att.com> wrote:
>
> +1 for Bryan’s point.
>
>
>
> If a project requests its docs to be included in release documentation,
> and it meets milestones and other quality metrics and won’t pose any
> adversary effects on release schedule, it should be included.
>
>
>
> Many documentation provides “knowledge”, as Heather indicated in a
> separate thread, and is very valuable to industry.
>
>
>
> Thanks
>
> Bin
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *SULLIVAN,
> BRYAN L
> *Sent:* Tuesday, September 06, 2016 9:40 AM
> *To:* Georg Kunz <georg.k...@ericsson.com>; Adi Molkho <
> adi.mol...@huawei.com>; Sofia Wallin <sofia.wal...@ericsson.com>;
> Kunzmann, Gerald <kunzm...@docomolab-euro.com>; Daniel Smith <
> daniel.sm...@ericsson.com>; David McBride <dmcbr...@linuxfoundation.org>;
> Christopher Price <christopher.pr...@ericsson.com>
> *Cc:* opnfv-tech-discuss@lists.opnfv.org
> *Subject:* Re: [opnfv-tech-discuss] How are Documentation/Reference
> Projects Published in C release
>
>
>
> Security Advisory:* This Message Originated Outside of AT ***
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
>
> My take is that we have projects, and those projects create documents that
> are optionally (on request of the project) included in the release
> documentation. We need go no further than that. Labelling projects
> (something I thought we had moved away from) or types of documents/focuses
> (e.g. requirements) and applying different policies as to what/how they are
> included in the release documentation, is unnecessary and ultimately
> confusing to the community.
>
>
>
> As an example, my Copper project documentation
> <http://artifacts.opnfv.org/copper/docs/design/index.html> 

Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release

[Georg Kunz]

Hi Edgar,

Would a document repository really solve our problem here? What do we mean by 
“current documents”? Aren’t the gaps we identify somehow related to the state 
of the upstream projects we build an OPNFV release on? So, while a requirements 
doc will certainly be a living document across OPNFV releases, relating a 
specific version of a requirements to a given release also gives an insight 
into the gaps at the time of a particular release.

If there is no change in the upstream projects that impacts the requirements 
analysis, then we just keep the document as it is – because the same gaps still 
exist. This would be in line with how we handle code between releases: If a 
project did not add a new feature from B to C, then C basically includes the 
same codebase and features (ignoring changes due to maintenance/ new tests 
here).

I perfectly understand David’s wish to have some form of tracking – just so 
much that release management is aware of the state and the goals. Bin’s 
suggestion to apply a subset of the existing milestones sound good to me.

Best regards
Georg

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of stpierre, edgar
Sent: Wednesday, September 07, 2016 3:17 AM
To: SULLIVAN, BRYAN L; David McBride; HU, BIN
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

There is no reason that I have seen that document delivery projects need to be 
part of a release project. Just have each document delivery be its own project, 
and the project teams should manage their own definition, creation, and review 
process and milestones for each document. A repository of “current documents” 
should be the intended placement for these – not a release, since these are 
sometimes independent of releases. E.g., why would we update a requirements 
document from Brahmaputra to Colorado if there’s been no change in the upstream 
and no change in the requirements? And have we been maintaining such documents 
from release to release when the upstream has changed?

-edgar

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]<mailto:[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]>
 On Behalf Of SULLIVAN, BRYAN L
Sent: Tuesday, September 06, 2016 6:47 PM
To: David McBride; HU, BIN
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

David,

To a point I put into my comments, there is no such thing as a “requirements 
project” in OPNFV anymore. There are projects, and they have artifacts. If the 
artifacts are simply documents, there are quality gates that govern them (the 
gerrit commit review process), and project schedule gates as well.

I’m not sure what you mean as “quality metrics” for code contributed in a 
release, other than gerrit reviews, tests, and project milestones. So I would 
suggest not to push the analogy too far with documents, as the basis for 
holding code up as an example is questionable other than the very same things 
that apply for documents: reviews, tests (to the extent that we test documents 
as suggested on the opnfvdocs project wiki) and milestones.

Thanks,
Bryan Sullivan | AT

From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Tuesday, September 06, 2016 1:00 PM
To: HU, BIN
Cc: SULLIVAN, BRYAN L; Georg Kunz; Adi Molkho; Sofia Wallin; Kunzmann, Gerald; 
Daniel Smith; Christopher Price; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Bin,

You hit on a key point:  "meets milestones and other quality metrics".  One 
reason that I question whether requirements projects should join a release is 
that the requirements projects associated with Colorado responded with "N/A" 
for most or all of their milestone reporting.  That's understandable, since the 
milestones are oriented toward projects that are creating or modifying code.  
I'm not aware of any quality metrics that they have been subjected to.

So, that raises the question, should requirements projects be tracked in a 
release?  If so, what milestones or other metrics should be used to track them?

David

On Tue, Sep 6, 2016 at 12:07 PM, HU, BIN 
<bh5...@att.com<mailto:bh5...@att.com>> wrote:
+1 for Bryan’s point.

If a project requests its docs to be included in release documentation, and it 
meets milestones and other quality metrics and won’t pose any adversary effects 
on release schedule, it should be included.

Many documentation provides “knowledge”, as Heather indicated in a separate 
thread, and is very valuable to industry.

Thanks
Bin

From: 

Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release

[HU, BIN]

David,

I think we can brainstorm how to better manage those projects that produce docs 
only in D Release, including requirement projects.

For example, when we set up milestones, we can define which milestones are 
applicable to those projects that produce docs only. Just like we defined one 
milestone in Colorado was only applicable to installer projects, and all other 
projects needed to answer “N/A”. “Feature Freeze” could be applicable, because 
those projects should know the outline / toc of the docs they want to produce. 
Other milestones may not be applicable, but documentation-ready is certainly 
applicable.

Regarding other quality metrics, I think the projects should have proofread 
their docs, and validated the technical content in their docs. And each subject 
is a different domain, so it is hard to define other quality metrics. Thus we 
may not need other quality metrics for docs but (1) correct technical content 
(2) proofread and signed off by PTL.

In summary, all I am suggesting is that there is a way to manage those 
projects, and the way is even much easier because there is no code. Based on 
current milestones, we can define a subset of milestones that are applicable to 
them. This way, all projects are included, and it is up to them to produce 
deliverables. If they miss a milestone, for example, if they have no idea what 
to write by feature freeze, probably they may not be able to produce a high 
quality doc with correct technical content by the release date.

Thanks
Bin

From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Tuesday, September 06, 2016 1:00 PM
To: HU, BIN <bh5...@att.com>
Cc: SULLIVAN, BRYAN L <bs3...@att.com>; Georg Kunz <georg.k...@ericsson.com>; 
Adi Molkho <adi.mol...@huawei.com>; Sofia Wallin <sofia.wal...@ericsson.com>; 
Kunzmann, Gerald <kunzm...@docomolab-euro.com>; Daniel Smith 
<daniel.sm...@ericsson.com>; Christopher Price 
<christopher.pr...@ericsson.com>; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Bin,

You hit on a key point:  "meets milestones and other quality metrics".  One 
reason that I question whether requirements projects should join a release is 
that the requirements projects associated with Colorado responded with "N/A" 
for most or all of their milestone reporting.  That's understandable, since the 
milestones are oriented toward projects that are creating or modifying code.  
I'm not aware of any quality metrics that they have been subjected to.

So, that raises the question, should requirements projects be tracked in a 
release?  If so, what milestones or other metrics should be used to track them?

David

On Tue, Sep 6, 2016 at 12:07 PM, HU, BIN 
<bh5...@att.com<mailto:bh5...@att.com>> wrote:
+1 for Bryan’s point.

If a project requests its docs to be included in release documentation, and it 
meets milestones and other quality metrics and won’t pose any adversary effects 
on release schedule, it should be included.

Many documentation provides “knowledge”, as Heather indicated in a separate 
thread, and is very valuable to industry.

Thanks
Bin

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>]
 On Behalf Of SULLIVAN, BRYAN L
Sent: Tuesday, September 06, 2016 9:40 AM
To: Georg Kunz <georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>; Adi 
Molkho <adi.mol...@huawei.com<mailto:adi.mol...@huawei.com>>; Sofia Wallin 
<sofia.wal...@ericsson.com<mailto:sofia.wal...@ericsson.com>>; Kunzmann, Gerald 
<kunzm...@docomolab-euro.com<mailto:kunzm...@docomolab-euro.com>>; Daniel Smith 
<daniel.sm...@ericsson.com<mailto:daniel.sm...@ericsson.com>>; David McBride 
<dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>>; 
Christopher Price 
<christopher.pr...@ericsson.com<mailto:christopher.pr...@ericsson.com>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

***Security Advisory: This Message Originated Outside of AT ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
My take is that we have projects, and those projects create documents that are 
optionally (on request of the project) included in the release documentation. 
We need go no further than that. Labelling projects (something I thought we had 
moved away from) or types of documents/focuses (e.g. requirements) and applying 
different policies as to what/how they are included in the release 
documentation, is unnecessary and ultimately confusing to the community.

As an exa

Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release

[Georg Kunz]

Hi Adi,

We had a discussion on this in the docs meeting last week and to my 
understanding we came to the agreement that the requirement docs should be 
included. The exact location and the naming still needs to be decided upon. For 
instance, it should be clear for users of the release that the requirement docs 
do NOT describe features which are available in the release. One proposal is to 
add a section to the documentation library called “Requirement Analyses” (my 
favorite) or “Future Work” (indicating that the requirements identified by the 
requirement docs will hopefully be addressed in future releases.

I hope we can conclude on the details soon, either here on the list or in 
tomorrow’s docs meeting.

Georg

From: Adi Molkho [mailto:adi.mol...@huawei.com]
Sent: Tuesday, September 06, 2016 3:40 PM
To: Sofia Wallin; Kunzmann, Gerald; Georg Kunz; Daniel Smith; David McBride; 
Christopher Price
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi
Is there any final conclusion to this mail thread ? Are the documents of the 
requirement project going to be part of the C release?

Thanks
Adi



From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]<mailto:[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]>
 On Behalf Of Sofia Wallin
Sent: Wednesday, August 31, 2016 1:42 PM
To: Kunzmann, Gerald; Georg Kunz; Daniel Smith; David McBride; Christopher Price
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi everyone,
I haven’t been involved in the discussion whether we want the requirement 
projects to be a part of our releases or not.
But when it comes to documentation it is obvious that people see a need to 
include this kind of work as well.
I agree with Chris, “to publish a “future work” section of our release library 
that describes more where our community is heading”.

I talked to Daniel yesterday and we think that it would be fine to handle this 
in the same way as the release documentation. We create an introduction 
document explaining what this is about and link to the projects documentation.


But let’s discuss this (and hopefully agree),
I will add this as topic for the docs meeting this afternoon, so people 
concerned are welcome to call in.

BR,
Sofia

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Kunzmann, 
Gerald
Sent: den 31 augusti 2016 09:51
To: Georg Kunz; Daniel Smith; David McBride
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi David, all,

My 2 cent on your question:

The question is: does it make sense for requirements projects to participate in 
releases until they're ready to deliver code?

Requirement projects are an essential part of OPNFV and some may even do all 
development in upstream, i.e. there might even be no code within OPNFV except 
test cases. Thus, I support having the requirement documents as part of the 
release documentation.

Best regards,
Gerald

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Georg Kunz
Sent: Mittwoch, 31. August 2016 09:42
To: Daniel Smith <daniel.sm...@ericsson.com<mailto:daniel.sm...@ericsson.com>>; 
David McBride 
<dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi Daniel, hi all,

Thank you Daniel for stating the advantages for the requirements projects and 
for OPNFV. From my point of view it is important for projects which are 
currently in the “requirements phase” to be represented in an OPNFV release:


-  We are in the process of reaching out to the OpenStack community 
based on our document. Making the requirements document an official part of an 
OPNFV release helps us in doing that by having an “official backing” of OPNFV 
(we are an OPNFV project after all)

-  It shows to the outside world that projects are active in all phases 
(requirements phase), supporting the overall perception of OPNFV

-  It gives the project members the feeling of contributing to OPNFV


I had some discussions with Chris and Sofia on this during the OPNFV summit. 
Back then the proposal was to include our requirements document in the 
“document library” under a section su

Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release

[Adi Molkho]

Hi
Is there any final conclusion to this mail thread ? Are the documents of the 
requirement project going to be part of the C release?

Thanks
Adi



From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Sofia Wallin
Sent: Wednesday, August 31, 2016 1:42 PM
To: Kunzmann, Gerald; Georg Kunz; Daniel Smith; David McBride; Christopher Price
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi everyone,
I haven’t been involved in the discussion whether we want the requirement 
projects to be a part of our releases or not.
But when it comes to documentation it is obvious that people see a need to 
include this kind of work as well.
I agree with Chris, “to publish a “future work” section of our release library 
that describes more where our community is heading”.

I talked to Daniel yesterday and we think that it would be fine to handle this 
in the same way as the release documentation. We create an introduction 
document explaining what this is about and link to the projects documentation.


But let’s discuss this (and hopefully agree),
I will add this as topic for the docs meeting this afternoon, so people 
concerned are welcome to call in.

BR,
Sofia

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Kunzmann, 
Gerald
Sent: den 31 augusti 2016 09:51
To: Georg Kunz; Daniel Smith; David McBride
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi David, all,

My 2 cent on your question:

The question is: does it make sense for requirements projects to participate in 
releases until they're ready to deliver code?

Requirement projects are an essential part of OPNFV and some may even do all 
development in upstream, i.e. there might even be no code within OPNFV except 
test cases. Thus, I support having the requirement documents as part of the 
release documentation.

Best regards,
Gerald

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Georg Kunz
Sent: Mittwoch, 31. August 2016 09:42
To: Daniel Smith <daniel.sm...@ericsson.com<mailto:daniel.sm...@ericsson.com>>; 
David McBride 
<dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi Daniel, hi all,

Thank you Daniel for stating the advantages for the requirements projects and 
for OPNFV. From my point of view it is important for projects which are 
currently in the “requirements phase” to be represented in an OPNFV release:


-  We are in the process of reaching out to the OpenStack community 
based on our document. Making the requirements document an official part of an 
OPNFV release helps us in doing that by having an “official backing” of OPNFV 
(we are an OPNFV project after all)

-  It shows to the outside world that projects are active in all phases 
(requirements phase), supporting the overall perception of OPNFV

-  It gives the project members the feeling of contributing to OPNFV


I had some discussions with Chris and Sofia on this during the OPNFV summit. 
Back then the proposal was to include our requirements document in the 
“document library” under a section such as “requirements projects”. This could 
be a simple link – just as we have it right now on our project wiki.

As David pointed out, there is some overhead involved for the project, but I 
believe the benefits outweigh the overhead.

Looking forward to discussing with you in today’s docs meeting.

Best regards
Georg

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Daniel Smith
Sent: Tuesday, August 30, 2016 11:44 PM
To: David McBride
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hey All.

I spoke with Sofia as well about this and presented our NetReady situation. We 
have a document that covers what we wanted to cover for Phase 1 (targeting C 
release) of the NetReady Requirements Project.   We now want to stop internally 
editing it and release it for comment – and the thinking is that, since we have 
built the document in gerrit and based on DOCS formatting guidelines, was the 
vehicle to provide the following in terms of the work that the 

Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release

[Christopher Price]

Hi Folks,

 

We may have a definition issue here as I think we are all doing the right 
things as far as we have defined them.

 

Not part of the release:

Documents describing requirements are not tracked, nor required to pass 
specific milestones for a release.  The only milestone that is important is 
docs freeze and what is available is up to the project writing the docs and is 
not coordinated by the release project.

 

Delivered with Colorado:

Requirement or descriptive docs can be included in the document publication of 
release artifacts by including them on the release page as we did in 
Brahmaputra.

This is OK as long as we are able to differentiate documentation of delivered 
platform capability and documentation of planned or projected capability.  
(Future requirements should not be in the same document as the release 
description)

Talk to your friendly docs team about these types of docs you would like to 
have included in the “Colorado library”.

 

Hope this helps clear things up.

 

As we discussed after Brahmaputra, but not acted upon yet.  It would be great 
for our projects doing “requirements documentation” to collaborate on some form 
of structure, standard and template with the docs team to make this more 
consistent and automated.

 

/ Chris 

 

From: <opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of David McBride 
<dmcbr...@linuxfoundation.org>
Date: Wednesday 31 August 2016 at 16:58
To: "Kunzmann, Gerald" <kunzm...@docomolab-euro.com>
Cc: TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

 

Hi Gerald,

 

I'm certainly aware that many project do most, or even all, of their work 
upstream.  When I say "deliver code", that includes making changes in upstream 
projects.  

 

Also, to be clear, I'm NOT saying that requirements projects should not be part 
of OPNFV, I'm just saying that I do not see the benefit of a project joining a 
release if their only activity is writing a requirements document.  Join the 
OPNFV project, write a requirements document, then join a release.  

 

Perhaps I'm missing something, though.  What benefit do you see in the release 
process for projects that are only writing requirements?  Why could that not be 
done as part of the OPNFV project, but outside of the release process?

 

David

 

 

 

On Wed, Aug 31, 2016 at 12:51 AM, Kunzmann, Gerald 
<kunzm...@docomolab-euro.com> wrote:

Hi David, all,

 

My 2 cent on your question:

 

The question is: does it make sense for requirements projects to participate in 
releases until they're ready to deliver code?

 

Requirement projects are an essential part of OPNFV and some may even do all 
development in upstream, i.e. there might even be no code within OPNFV except 
test cases. Thus, I support having the requirement documents as part of the 
release documentation.

 

Best regards,

Gerald

 

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Georg Kunz
Sent: Mittwoch, 31. August 2016 09:42
To: Daniel Smith <daniel.sm...@ericsson.com>; David McBride 
<dmcbr...@linuxfoundation.org>


Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

 

Hi Daniel, hi all,

 

Thank you Daniel for stating the advantages for the requirements projects and 
for OPNFV. From my point of view it is important for projects which are 
currently in the “requirements phase” to be represented in an OPNFV release:

 

-  We are in the process of reaching out to the OpenStack community 
based on our document. Making the requirements document an official part of an 
OPNFV release helps us in doing that by having an “official backing” of OPNFV 
(we are an OPNFV project after all)

-  It shows to the outside world that projects are active in all phases 
(requirements phase), supporting the overall perception of OPNFV

-  It gives the project members the feeling of contributing to OPNFV

 

I had some discussions with Chris and Sofia on this during the OPNFV summit. 
Back then the proposal was to include our requirements document in the 
“document library” under a section such as “requirements projects”. This could 
be a simple link – just as we have it right now on our project wiki.

 

As David pointed out, there is some overhead involved for the project, but I 
believe the benefits outweigh the overhead. 

 

Looking forward to discussing with you in today’s docs meeting.

 

Best regards

Georg

 

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Daniel Smith
Sent: Tuesday, August 30, 2016 11:44 PM
To: David McBride
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation

Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release

[David McBride]

Hi Gerald,

I'm certainly aware that many project do most, or even all, of their work
upstream.  When I say "deliver code", that includes making changes in
upstream projects.

Also, to be clear, I'm NOT saying that requirements projects should not be
part of OPNFV, I'm just saying that I do not see the benefit of a project
joining a release if their only activity is writing a requirements
document.  Join the OPNFV project, write a requirements document, then join
a release.

Perhaps I'm missing something, though.  What benefit do you see in the
release process for projects that are only writing requirements?  Why could
that not be done as part of the OPNFV project, but outside of the release
process?

David



On Wed, Aug 31, 2016 at 12:51 AM, Kunzmann, Gerald <
kunzm...@docomolab-euro.com> wrote:

> Hi David, all,
>
>
>
> My 2 cent on your question:
>
>
>
> The question is: does it make sense for requirements projects to
> participate in releases until they're ready to deliver code?
>
>
>
> Requirement projects are an essential part of OPNFV and some may even do
> all development in upstream, i.e. there might even be no code within OPNFV
> except test cases. Thus, I support having the requirement documents as part
> of the release documentation.
>
>
>
> Best regards,
>
> Gerald
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *Georg Kunz
> *Sent:* Mittwoch, 31. August 2016 09:42
> *To:* Daniel Smith <daniel.sm...@ericsson.com>; David McBride <
> dmcbr...@linuxfoundation.org>
>
> *Cc:* opnfv-tech-discuss@lists.opnfv.org
> *Subject:* Re: [opnfv-tech-discuss] How are Documentation/Reference
> Projects Published in C release
>
>
>
> Hi Daniel, hi all,
>
>
>
> Thank you Daniel for stating the advantages for the requirements projects
> and for OPNFV. From my point of view it is important for projects which are
> currently in the “requirements phase” to be represented in an OPNFV release:
>
>
>
> -  We are in the process of reaching out to the OpenStack
> community based on our document. Making the requirements document an
> official part of an OPNFV release helps us in doing that by having an
> “official backing” of OPNFV (we are an OPNFV project after all)
>
> -  It shows to the outside world that projects are active in all
> phases (requirements phase), supporting the overall perception of OPNFV
>
> -  It gives the project members the feeling of contributing to
> OPNFV
>
>
>
> I had some discussions with Chris and Sofia on this during the OPNFV
> summit. Back then the proposal was to include our requirements document in
> the “document library” under a section such as “requirements projects”.
> This could be a simple link – just as we have it right now on our project
> wiki.
>
>
>
> As David pointed out, there is some overhead involved for the project, but
> I believe the benefits outweigh the overhead.
>
>
>
> Looking forward to discussing with you in today’s docs meeting.
>
>
>
> Best regards
>
> Georg
>
>
>
> *From:* opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:
> opnfv-tech-discuss-boun...@lists.opnfv.org] *On Behalf Of *Daniel Smith
> *Sent:* Tuesday, August 30, 2016 11:44 PM
> *To:* David McBride
> *Cc:* opnfv-tech-discuss@lists.opnfv.org
> *Subject:* Re: [opnfv-tech-discuss] How are Documentation/Reference
> Projects Published in C release
>
>
>
> Hey All.
>
>
>
> I spoke with Sofia as well about this and presented our NetReady
> situation. We have a document that covers what we wanted to cover for Phase
> 1 (targeting C release) of the NetReady Requirements Project.   We now want
> to stop internally editing it and release it for comment – and the thinking
> is that, since we have built the document in gerrit and based on DOCS
> formatting guidelines, was the vehicle to provide the following in terms of
> the work that the team did:
>
>
>
> -Allow for the completion and publishing of the Project Goals
> Phase 1 targets (in line with agreed principles when the project  was
> approved/started) – Phase2,3,4 as outlined are targeted for subsequent
> releases as documented
>
> -Allow for the distribution of the finished product to external
> (non commiter/contributer groups) -  is it realistic to think that someone
> from Openstack (whom the requirements are destined for) will look at the
> RST line format in our gerrit repository to find our documentation? (rather
> than in the released docs page/artifact)?   Or perhaps a different way of
> looking at it would be to ask, how do we move the fin

Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release

[Sofia Wallin]

Hi everyone,
I haven’t been involved in the discussion whether we want the requirement 
projects to be a part of our releases or not.
But when it comes to documentation it is obvious that people see a need to 
include this kind of work as well.
I agree with Chris, “to publish a “future work” section of our release library 
that describes more where our community is heading”.

I talked to Daniel yesterday and we think that it would be fine to handle this 
in the same way as the release documentation. We create an introduction 
document explaining what this is about and link to the projects documentation.


But let’s discuss this (and hopefully agree),
I will add this as topic for the docs meeting this afternoon, so people 
concerned are welcome to call in.

BR,
Sofia

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Kunzmann, 
Gerald
Sent: den 31 augusti 2016 09:51
To: Georg Kunz; Daniel Smith; David McBride
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi David, all,

My 2 cent on your question:

The question is: does it make sense for requirements projects to participate in 
releases until they're ready to deliver code?

Requirement projects are an essential part of OPNFV and some may even do all 
development in upstream, i.e. there might even be no code within OPNFV except 
test cases. Thus, I support having the requirement documents as part of the 
release documentation.

Best regards,
Gerald

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Georg Kunz
Sent: Mittwoch, 31. August 2016 09:42
To: Daniel Smith <daniel.sm...@ericsson.com<mailto:daniel.sm...@ericsson.com>>; 
David McBride 
<dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>>
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hi Daniel, hi all,

Thank you Daniel for stating the advantages for the requirements projects and 
for OPNFV. From my point of view it is important for projects which are 
currently in the “requirements phase” to be represented in an OPNFV release:


-  We are in the process of reaching out to the OpenStack community 
based on our document. Making the requirements document an official part of an 
OPNFV release helps us in doing that by having an “official backing” of OPNFV 
(we are an OPNFV project after all)

-  It shows to the outside world that projects are active in all phases 
(requirements phase), supporting the overall perception of OPNFV

-  It gives the project members the feeling of contributing to OPNFV


I had some discussions with Chris and Sofia on this during the OPNFV summit. 
Back then the proposal was to include our requirements document in the 
“document library” under a section such as “requirements projects”. This could 
be a simple link – just as we have it right now on our project wiki.

As David pointed out, there is some overhead involved for the project, but I 
believe the benefits outweigh the overhead.

Looking forward to discussing with you in today’s docs meeting.

Best regards
Georg

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Daniel Smith
Sent: Tuesday, August 30, 2016 11:44 PM
To: David McBride
Cc: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects 
Published in C release

Hey All.

I spoke with Sofia as well about this and presented our NetReady situation. We 
have a document that covers what we wanted to cover for Phase 1 (targeting C 
release) of the NetReady Requirements Project.   We now want to stop internally 
editing it and release it for comment – and the thinking is that, since we have 
built the document in gerrit and based on DOCS formatting guidelines, was the 
vehicle to provide the following in terms of the work that the team did:


-Allow for the completion and publishing of the Project Goals Phase 1 
targets (in line with agreed principles when the project  was approved/started) 
– Phase2,3,4 as outlined are targeted for subsequent releases as documented

-Allow for the distribution of the finished product to external (non 
commiter/contributer groups) -  is it realistic to think that someone from 
Openstack (whom the requirements are destined for) will look at the RST line 
format in our gerrit repository to find our documentation? (rather than in the 
released docs page/artifact)?   Or perhaps a different way of looking at it 
would be to ask, h

[opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release

[Daniel Smith]

Hey David and Sofia.

In the NetReady group, we have structured our documentation and commits for our 
C-release documentation in RST format/doc guidelines under the auspices that 
this was required so that when the DOCS are generated for the release, 
requirements and documentation projects deliveries are included in the release.

In our meeting there was some confusion as to how Requirements Projects, that 
delivery requirements documents (which are finalized for this phase and then 
later phases - prototyping, etc occurs for D release, based on the C 
deliveable) are actually included in the release.  Some input was that 
Requirements projects, since they don't deliver code are not part of the 
release? That didn't sound correct me, so please clarify when you have time.

Thank you


[Ericsson]

Daniel Smith
Sr. System Designer
Ericsson Inc.
8400 Decarie Blvd.  Montreal, PQ
(514)-594-2799

[http://www.ericsson.com/current_campaign]

Legal entity: Ericsson AB, registered office in Stockholm. This Communication 
is Confidential. We only send and receive email on the basis of the terms set 
out at 
www.ericsson.com/email_disclaimer

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss