Hey Scott,

I got a chance to take a look at your demo app. It's nice! I think your 
proposal is a good idea. A lot of effort went into creating this library for 
the use in NiFi Registry (awesome work on that!), and its pretty cool that 
something came out of it that can stand on its own to be shared across all NiFi 
UIs... and potentially other projects if they're interested.

Others have pointed out that every sub-project we add will create a bit of 
additional effort in order to be supported by the community. This is true, so 
these decisions should be thoughtfully considered. A like this particular case, 
because in addition to the project structure benefits, a standalone sub-project 
also has the potential to create a nice sub-community for our front-end 
contributors within the NiFi project, where they can explore new ideas, develop 
a roadmap for consistency across all NiFi UIs, and grow a group of front-end 
specialists [1].

Lastly, I think Scott makes a good point that automated testing good coverage 
and a RTC pattern of introducing code changes can and should reduce the burden 
on reviewers at release time [2]. I've noticed in Scott's example repo that 
even the process of versioning and packaging has been automated to work easily 
with NPM, so even the package structure should be reliably generated. There are 
still things that need to be verified manually in every release, such as the 
LICENSE/NOTICE (although hopefully a lot of that is getting verified in PR 
reviews), but if we focus on identifying in the Release Helper's Guide exactly 
what the manual review needs to include and how to do it (versus which things 
we are confident that our tests running on Travis CI have verified) we could 
streamline the validation process. With more subprojects, the amount to 
validate in each individual one should be smaller, too (ie, there are fewer 
front-end libraries to verify license compatibility in NiFi Registry because 
that will be done as part of Fluid Design System releases), and we can spread 
that burden out to a larger group over time.

[1] I don't want to be misunderstood - I'm not implying that our current 
front-end contributors aren't awesome (quite the opposite!), or that there 
aren't benefits to having "everyone work a bit on everything." I just think 
it's important to keep in mind that as a project's codebase grows, it can be 
hard for newcomers to find exactly where and how to contribute, and this would 
create a nice self-contained project for someone interested in exploring the UX 
code. If you want to work on everything in this codebase, you'll still be able 
to :)

[2] "Master is always releasable" is the philosophy of those who practice 
continuous deployment. I'm *not* suggesting we adopt CD, but there are valuable 
takeaways to learn from that approach, and it's possible to adopt some of them 
as a means of keeping the master branch extremely stable, even if we're only 
cutting releases periodically.

´╗┐On 2/22/18, 13:43, "Scott Aslan" <scottyas...@gmail.com> wrote:

    Yes, extract out the FDS.
    As for a release schedule, I don't think there would need to be one. We
    would put out new releases as needed for new features or components. These
    releases would be totally independent of NiFi or NiFi Registry. The
    intention with this project is to follow semantic versioning and avoid
    making breaking changes so using this library in NiFi or the NiFi Registry
    would be as simple as updating the version number in the package.json and
    rebuilding the application.
    As for validation of releases I have a couple of ideas. I envisioned this
    code base would follow a RTC paradigm and the initial release of this FDS
    NgModule would include unit test coverage of all the existing
    features/components/utils. Any new features/components/utils would require
    adequate test coverage before being merged to NiFi FDS master. We could
    also provide a demo application that users can build and deploy locally to
    allow for human verification or even e2e testing...
    I took the liberty of standing up a repo to give everyone a better idea of
    what we are all talking about.
    Since no server or backend is required to run these UI/UX components I also
    stood a demo of this as a github.io page here:
    On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt <joe.w...@gmail.com> wrote:
    > Scott
    > Ok so extract out the fluid design work you started with NiFi Registry
    > to its own codebase which can be rev'd and published to NPM making it
    > easier to consume/reuse across NiFi projects and offers better
    > consistency.  This sounds interesting.
    > In thinking through the additional community effort or the effort
    > trade-off:
    > How often do you anticipate we'd be doing releases (and thus
    > validation/voting) for this?
    > How often would those differ from when we'd want to do a NiFi or NiFi
    > Registry release?
    > How do you envision the community would be able to help vet/validate
    > releases of these modules?
    > Thanks
    > Joe
    > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan <scottyas...@gmail.com>
    > wrote:
    > > NiFi Community,
    > >
    > > I'd like to initiate a discussion around creating a sub-project of NiFi
    > to
    > > encompass the Fluid Design System NgModule created during the 
    > > of the NiFi Registry. A possible name for this sub-project is simply
    > > "NiFi Fluid
    > > Design System". The idea would be to create a sub-project that
    > distributes
    > > an atomic set of high quality, reuse-able, theme-able, and testable 
    > > components, fonts, and other JS modules for use across the various web
    > > applications throughout the NiFi universe (uNiFiverse???). Both NiFi and
    > > NiFi Registry web applications would eventually leverage this module via
    > > npm. This approach will enable us to provide our users with a consistent
    > > experience across web applications. Creating a sub-project would also
    > allow
    > > the FDS code to evolve independently of NiFi/NiFi registry and be
    > released
    > > on it's own timeline. In addition, it would make tracking issues/work
    > much
    > > clearer through a separate JIRA.
    > >
    > > Please discuss and provide and thoughts or feedback.
    > >
    > > Thanks,
    > >
    > > Scotty

Reply via email to