nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Aslan <scottyas...@gmail.com>
Subject Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System
Date Thu, 01 Mar 2018 15:07:47 GMT
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 <scottyaslan@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 <tkurc@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" <scottyaslan@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 <
>> sivaprasanna246@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.gilman@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 <
>> jpercivall@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 <
>> > mikerthomsen@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.witt@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 <
>> > > scottyaslan@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: jpercivall@apache.com
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message