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 <[email protected]> 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 <[email protected]> > 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 > > [email protected] > > [email protected] > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > >
