On Tue, Jul 17, 2018 at 11:39 AM, Mike Percy <mpe...@apache.org> wrote:
> Hi Apache Kudu community, > > Apologies for cross-posting, we just wanted to reach a broad audience for > this topic. > > Grant and I have been brainstorming about what we can do to grow the > community of Kudu developers and users. We think Kudu has a lot going for > it, but not everybody knows what it is and what it’s capable of. Focusing > and combining our collective efforts to increase awareness (marketing) and > to reduce barriers to contribution and adoption could be a good way to > achieve organic growth. > > We’d like to hear your ideas about what barriers and pain points exist and > any ideas you may have to fix some of those things -- especially ideas > requiring minimal effort and maximum impact. > > To kick this off, here are some ideas Grant and I have come up with so far, > in sort of a rough priority order: > > Ideas for general improvements > > 1. Java MiniCluster support out of the box (KUDU-2411) > 1. This will enable integration with other projects in a way that allows > them to test against a running Kudu cluster and ensure quality > without > having to build it themselves. > 2. Create a dedicated Maven-consumable java module for a Kudu > MiniCluster > 3. Pre-built binary artifacts (for testing use only) downloadable > with MiniCluster (Linux / MacOS) > 4. Ship all dependencies (even security deps, which will not be fixed > if CVEs found) > 5. Make the binaries Linux distro-independent by building on an old > distro (EL6) > 2. Upgrade Gerrit to fix the “New UI” GitHub Login Bug (KUDU-2402) > 1. Remove barrier to submitting a patch > 2. Latest version of Gerrit has a fix for the bad GitHub login > redirect > 3. Upstream pre-built packages for production use (Start rhel7, maybe > ubuntu) > 1. This is potentially a pretty large effort, depending in the number of > platforms we want to support > 2. Tarballs -- per-OS / per-distro > 3. Yum install, apt get: per-OS / per-distro > 4. Homebrew? > 4. CLI based tools with zero dependencies for quick experiments/demos > 1. Create, describe, alter tables > 2. Cat data out, pipe data in. > A suggestion to add on to the easily downloadable pre-built packages, is to have easily accessible/downloadable example test-data that's fairly representative of real world datasets (but it doesn't have to be too large). Additionally, we can write tutorials in kudu/examples/ that use this test data, to give new users a better feel for the system. > 3. Or simple Python examples to do similar > 5. Create developer oriented docs and faqs (wiki style?) > 6. CONTRIBUTING.adoc in repo > 1. Simplified > 2. Quick “assume nothing tutorial” > 3. Video Guide? > > Ongoing marketing and engagement > > 1. Quarterly email to the dev / users list > 1. Recognize new contributors > 2. Call out beginner jiras > 3. Summarize ongoing projects > 2. Consistently use the beginner / newbie tag in JIRA > 1. Doc how to find beginner jiras in the contributing docs > 3. Regular blog posts > 1. Developer and community contributors > 2. Invite people from other projects that integrate w/ Kudu to post > on our Blog > 3. Document how to contribute a blog post > 4. Topics: Compile and maintain a list of blog post ideas in case > people want inspiration -- Grant has been gathering ideas for this > 4. Archive Slack to a mailing list to be indexed by search engines > (SlackArchive.io has shut down) > > Please offer your suggestions for where we can get a good bang for our > collective buck, and if there is anything you would like to work on by all > means please either speak up or feel free to reach out directly. > > Thanks, > > Grant and Mike >
