I'm pretty open-- certainly more so than I was in 2014 😀
Back then, I created a flow chart that started with the whole approach to a
new project being created and out of that whole process, only one item is
still in the current process-- the need to reference a particular NFV
standard that is being addressed.
The thought, back then was to provide a mechanism where we could identify
whether we were implementing a standard or creating a new one. If
implementing then I felt we were doing a good thing. If, however, we were
implementing a marketing requirement that did readily have a corresponding
standard associated with it, I felt it was worth documenting and
socializing it to the relevant SDO so that they wouldn't ultimately turn
around and re-invent the wheel.
That was at the onset of a new project being created.
On the backend of things, I felt it was needed to put a similar mechanism
in place to help us get our patches adopted by any affected upstream
project. My premise was fairly simple back then. I actually thought we
would have more of our own code than we currently have. But I did think we
would be making changes to upstream projects to help things be more tightly
integrated and that there needed be a mechanism to help socialize them so
we might not have to maintain so many mods to such leveraged projects.
None of this was really intended to FORCE the projects to do anything, but
rather provide a documented process and list of stuff. Once we had such a
list and corresponding process, we could use that to help folks who had no
idea what to do to make their hard work more popular in other communities.
I also felt it was something we could monitor via software, much like we're
now doing with license and security scanning.
This could even be done at a WG level, so that the burden isn't 100% on a
project that is otherwise tapped for resources.
That was the idea. And I had some really nifty (at least in my mind at the
time, probably will make me vomit now) flow charts.
On Thu, Sep 22, 2016 at 3:10 PM, Heather Kirksey <
> On the "Requirements phase" discussion specifically:
> It might depend on what you, as a project, are interested in and what is
> helpful. As Dave says, we've generally taken a fairly laissez-faire
> approach to this, and it's generally resulted in a project using their
> requirements document as a project-internal tool to facilitate a set of
> upstream contributions as they've decided such blueprints, patches, Jira
> tickets, etc., make sense.
> If projects in this phase of their work think getting more eyes outside of
> the project would benefit their work, let's think about how to highlight
> some of this rather than waiting for extremely interested parties to visit
> the repo. Not to make work, but if requirements-phase projects think it
> would be beneficial.
> I think on a similar thread folks suggested a wiki page or something like
> that. It could perhaps be linked to on the general upstream blueprint
> progress tracking page (if that's even up to date) and perhaps our EUAG
> page (for end-user input).
> This wouldn't be something like a gate or requirement but a facilitation
> of information sharing. (This may or may not be related to some of what you
> were thinking, Ash).
> What do y'all as projects doing this work want? What serves your needs?
> On Thu, Sep 22, 2016 at 12:58 PM, Dave Neary <dne...@redhat.com> wrote:
>> On 09/20/2016 12:57 PM, Daniel Smith wrote:
>> > Several weeks ago as part of the inclusion of Requirements Projects, I
>> > asked how we know that people are looking at what we are producing in
>> > Requirements projects and how we (OPNFV) ensure that deliverables from
>> > Requirements projects are being reviewed and taken into account upstream
>> > (from an OPNFV overall standpoint).
>> > Would any of you be able to shed some light on this? The current
>> > impression that I have is we have the docs that sit in a repo and
>> that’s it.
>> To my knowledge, there is no formal process. It is up to individual
>> project members to reach out to the relevant upstream projects and
>> propose their changes there.
>> Dave Neary - NFV/SDN Community Strategy
>> Open Source and Standards, Red Hat - http://community.redhat.com
>> Ph: +1-978-399-2182 / Cell: +1-978-799-3338
> *Heather Kirksey*
> Director, OPNFV
> Mobile: +1.512.917.7938
> Email/Google Talk: hkirk...@linuxfoundation.org
> Skype: HeatherReneeKirksey
> IRC: HKirksey
> [image: OPNFV_RGB.png]
> opnfv-tech-discuss mailing list
opnfv-tech-discuss mailing list