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
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 . 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.
 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
 "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:
> 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
> 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?
> On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan <scottyas...@gmail.com>
> > NiFi Community,
> > I'd like to initiate a discussion around creating a sub-project of NiFi
> > 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
> > 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
> > the FDS code to evolve independently of NiFi/NiFi registry and be
> > on it's own timeline. In addition, it would make tracking issues/work
> > clearer through a separate JIRA.
> > Please discuss and provide and thoughts or feedback.
> > Thanks,
> > Scotty