nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Thomsen <mikerthom...@gmail.com>
Subject Re: Lowering the barrier of entry
Date Fri, 25 Jan 2019 16:06:59 GMT
One of the changes we should make is to create a separate guide for product
vendors on how to build and maintain a bundle. We're at that point where
vendors will have to do it on their own as extension providers, so it would
be very helpful for them to have a simple and straight forward document
showing them what should be there, best practices for maintainability and
where to announce it.

On Fri, Jan 25, 2019 at 9:59 AM Bryan Bende <bbende@gmail.com> wrote:

> I think we have a lot more documentation than most projects, but I
> think an issue is that content is scattered in many different
> locations, and some of the docs are huge reference guides where it can
> be hard to find all the pieces of what you are trying to do.
>
> The first thing a new contributor wants to do is get the code and run
> a build, and we do have a quick-start guide linked to on the site, but
> I think there is a lot of extra information in there that is not
> really relevant to someone just wanting get the code and build. We
> could have separate guides per OS like "Build NiFi on Linux", "Build
> NiFi on Windows", etc, where each guide was 4-5 steps like:
>
> - Clone repo
> - checkout master
> - run maven
> - cd to assembly
> - ./bin/nifi.sh
>
> The next thing they want to do is contribute a change, and we have a
> great contributor guide, but again I think there could be a very short
> tutorial for the most common steps:
>
> - fork repo
> - clone fork
> - create branch
> - make changes
> - push branch
> - submit pr
>
> and then say something like "for a more detailed description of the
> contribution process, please reference the Contributor Guide".
>
> If we then make these getting started guides more prominent right in
> the middle of the NiFi homepage, then maybe they will be easier to
> find for new community members.
>
> We can keep extending this idea to other common tasks beyond just
> building and contributing.
>
>
> On Thu, Jan 24, 2019 at 8:03 PM Andy LoPresto <alopresto@apache.org>
> wrote:
> >
> > Hi folks,
> >
> > Based on some recent (and long-term) experiences, I wanted to discuss
> with the community what we could do to lower the barrier of entry to using
> & contributing to NiFi. I hope to get some good feedback from both
> long-time and newer members, and determine some immediate concrete steps we
> can take.
> >
> > Problems identified:
> > * NiFi has a number of custom profiles, so a simple “mvn clean install”
> in project root doesn’t get a new developer up and running immediately
> > * The API is very well defined, but for new contributors, it can be a
> challenge to know where to put functionality, and building a custom
> processor + NAR and deploying isn’t a one-step process
> > * Project size (and build size/time) is large. This can restrict the
> minimum hardware necessary, elongate the development cycle, etc.
> > * Some new users do not receive mailing list replies
> >
> > Possible solutions:
> > * On a clean git clone, “mvn clean install” should build a working
> instance. Maybe we provide a quickstart.sh script to handle the default
> maven build, change to the target directory, and start NiFi?
> > * Individual contributors have written excellent blogs, and
> documentation exists, but making it more prominent or more easily accessed
> could help?
> > * Extension registry will solve all the world’s problems (related to
> bundling and build time)
> > * Not sure about this one — I don’t know if it’s because they’re not
> subscribed, their mail client is blocking them, etc.
> >
> > I’ve said my bit, now I am eager to hear from other community members on
> their experiences, steps that helped them, and suggestions for the future
> to continue to make the NiFi community welcoming to new users. Thanks.
> >
> >
> > Andy LoPresto
> > alopresto@apache.org
> > alopresto.apache@gmail.com
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
>

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