A couple of names I came up with: 1. chalk 2. depth 3. dew 4. cyan 5. mint
On Thu, Mar 1, 2018 at 8:37 PM, Scott Aslan <scottyas...@gmail.com> wrote: > Hello MikeM/everyone, > > One of the questions brought up in this discussion was centered around what > a design system is. I stumbled upon a really great article this morning on > this exact topic. It also links to several other really great articles and > will help us all to understand. > https://uxplanet.org/design-systems-in-2016-5415a660b29 > > Also, I was thinking about the name.... what does everyone think about > naming this sub-project NiFi Design System? > > -Scotty > > On Fri, Feb 23, 2018 at 10:20 AM, Scott Aslan <scottyas...@gmail.com> > wrote: > > > TonyK, > > > > The intent is to use this this NgModule in NiFi Registry and eventually > > NiFi. However, this would be released under ASLv2 so yes other projects > > could use it. > > > > On Thu, Feb 22, 2018 at 10:46 PM, Tony Kurc <tk...@apache.org> wrote: > > > >> Is some of the thinking that projects other than nifi projects would use > >> this? > >> > >> On Feb 22, 2018 10:00 PM, "Scott Aslan" <scottyas...@gmail.com> wrote: > >> > >> > Sivaprasanna, > >> > > >> > I am not sure I follow exactly what you are saying... > >> > > >> > NiFi Registry would no longer continue to host a copy of the FDS > >> NgModule. > >> > Instead, NiFi Registry would just add the NiFi FDS sub-project as a > >> client > >> > side dependency in its package.json. This would be analogous to how > NiFi > >> > Registry depends on Angular Material, etc. npm supports the ability to > >> > download published packages which are current with the latest stable > >> > release of a package. npm *also* supports the ability to develop off > >> > of the *master > >> > branch (or any other branch really)* of the NiFi FDS. An example of > this > >> > can be found in the github.io demo here > >> > <https://github.com/scottyaslan/fluid-design-system/blob/gh- > >> pages/package. > >> > json#L45> > >> > . By placing that dependency in the package.json for the NiFi Registry > >> each > >> > subsequent clean build would automatically download the latest master > >> > branch of the NiFi FDS sub-project and developers can leverages the > >> latest > >> > NiFi FDS components. > >> > > >> > This also brings up a good point about release management. I have also > >> > included a prototype of one possible implementation of automating the > >> > tagging of a branch and automatically updating release version numbers > >> etc. > >> > leveraging grunt-bump [1]. The FDS-0.0.1-RC.0 tag [2] was created with > >> the > >> > described grunt task. > >> > > >> > [1] > >> > https://github.com/scottyaslan/fluid-design-system/blob/ > >> master/Gruntfile. > >> > js#L47 > >> > > >> > [2] https://github.com/scottyaslan/fluid-design-system/tree/FDS- > >> 0.0.1-RC.0 > >> > > >> > On Thu, Feb 22, 2018 at 12:39 PM, Sivaprasanna < > >> sivaprasanna...@gmail.com> > >> > wrote: > >> > > >> > > I agree with Matt. With clear documentation and guides, > contributions > >> on > >> > > the sub-projects can be streamlined and be ensured that the > necessary > >> > > changes are already available on the core project i.e NiFi. One > >> challenge > >> > > is that the committer of the sub-project should have the courtesy to > >> > check > >> > > wether the supporting changes are made available to the core project > >> and > >> > > track its status but given how contributions are being handled in > >> > > nifi-registry project, I don’t think it’s going to be that much of a > >> > > headache. > >> > > > >> > > We could also add to the helper doc mentioning that if the > >> contribution > >> > is > >> > > going to affect a core component, the contributor needs to add the > >> JIRA > >> > id > >> > > of the core project’s supporting changes in the sub-projects’ issue > >> > > description. > >> > > > >> > > On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman < > matt.c.gil...@gmail.com > >> > > >> > > wrote: > >> > > > >> > > > Joe, Joe, > >> > > > > >> > > > Regarding the release process... I think it could be similar to > how > >> > folks > >> > > > verified and validated the NiFi Registry release. Guidance was > given > >> > in a > >> > > > helper guide regarding how to obtain/build a branch or PR that > >> > references > >> > > > the new components. For the Registry release, there was a PR for > >> NiFi > >> > > that > >> > > > had the supporting changes already available. > >> > > > > >> > > > We may have this issue any time we release new versions that > depend > >> on > >> > > > another (sub)project. > >> > > > > >> > > > Matt > >> > > > > >> > > > On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall < > >> jperciv...@apache.org > >> > > > >> > > > wrote: > >> > > > > >> > > > > Scott, > >> > > > > > >> > > > > Definitely like the direction of standardizing NiFi and Registry > >> > around > >> > > > the > >> > > > > same set of components, so the user has a common UX. Is there > >> > precedent > >> > > > for > >> > > > > creating a new sub-project just for common components/modules to > >> be > >> > > used > >> > > > by > >> > > > > the top-level, and it's other sub-projects? My concerns are > >> similar > >> > to > >> > > > > Joe's. Along those lines, if the core problems we're trying to > >> > address > >> > > is > >> > > > > the release process and distribution, is there a less > >> "heavy-weight" > >> > > > > avenue? > >> > > > > > >> > > > > In the past, we've also talked about pulling out the core NiFi > >> > > framework > >> > > > to > >> > > > > be shared between NiFi and MiNiFi-Java for similar reasons. How > >> we go > >> > > > about > >> > > > > solving this for the UI could be used a model for the core > >> framework > >> > as > >> > > > > well. > >> > > > > > >> > > > > - Joe > >> > > > > > >> > > > > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen < > >> > mikerthom...@gmail.com > >> > > > > >> > > > > wrote: > >> > > > > > >> > > > > > Also, what sort of framework is the UI being standardized on? > >> > > Angular? > >> > > > > > React? Something else? > >> > > > > > > >> > > > > > 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 > >> > > > > > 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 > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > -- > >> > > > > *Joe Percivall* > >> > > > > linkedin.com/in/Percivall > >> > > > > e: jperciv...@apache.com > >> > > > > > >> > > > > >> > > > >> > > >> > > > > >
