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" <[email protected]> wrote: Joe, 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. https://github.com/scottyaslan/fluid-design-system 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: https://scottyaslan.github.io/fluid-design-system/ <https://scottyaslan.github.io/fluid-design-system/> -Scotty On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt <[email protected]> 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 <[email protected]> > 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 development > > 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 UI/UX > > 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 >
