I'll detail why I think Tez is ready to graduate. Nobody is concerned about its activity, relevance, or ability to produce releases. So I won't belabor those points. Let's focus on whether the Tez project is approachable as a project and as a community.
Posting project plans and discussing them on JIRA does not appear to be a problem, now. Early in its incubation there were some periods of inactivity followed by a deluge of issues, filed and committed with minimal discussion. However, of the issues I'm watching recently, most of the discussion- including semantic issues much easier to work out intra-office- are on-list. By way of example, TEZ-1157 is one random issue I subscribe to: it discusses tradeoffs, cross-references other JIRAs, and is accessible to someone familiar with the problem, but not employed at Hortonworks. I haven't kept statistics, but I usually scan the list to track it's progress every couple weeks. Recently, my impression is that it's been a steady stream not only of code, but also debate. Before they were nominated as committers, I also recognized names from other organizations- like Mohammad Islam who I know from the Oozie project- interacting on the dev list and posting code. Going to the back of my archive, even early issues from external contributors- like TEZ-235- received review comments and attention from committers. When they appear, contributors are welcomed. Tez has been presented often and at many levels of detail. I doubt any source for contributors has been passed over deliberately, so if you know of meetups/hackathons where Tez might present: invite them. We should be equally frank about its challenges. Tez is not an easy project to learn. Some of this is a technical barrier that could be overcome by more documentation, wiki content (how to develop, where code lives, etc.), and strategies like maintaining a list of "newbie" issues. These are all reasonable expectations of an Apache project. Most contributors will put up with review comment latency, but orientation could be less painful than it is. That these materials are not developed speaks to the effect that Ted alludes to: most people who work on Tez have a compelling, professional reason to propel them through the steep learning curve. The code is less volatile than it was initially, so an investment in docs could be worthwhile. All of these are suggestions for that community to grow its base and are not a prerequisite for graduation. The project cuts releases, develops actively in the open, and has absorbed the incubator curriculum. Its members are aware of the challenges discussed in this thread and will report on them to the board. In short, the community can be trusted with all the autonomy of a TLP; continued incubation serves no purpose. If there exists a problem the IPMC can solve- NOTICE/LICENSE improperly maintained, education on ASF resources/policy, bad release hygiene- then great, let's fix it. If not, then this incubation has concluded and we can recommend it to the board as a TLP. -C On Mon, Jun 23, 2014 at 2:41 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: > On Mon, Jun 23, 2014 at 2:23 PM, Bikas Saha <bi...@hortonworks.com> wrote: > >> Community building is an organic process that grows on its own accord. >> > > Really, I was going to run away for a bit, but my feeling is that this > statement is amazingly naive about how communities are built. > > Community doesn't just happen. Community doesn't just grow of its own > accord. Community grows when people make serious, explicit actions to help > it grow, to bring in newcomers, to publish plans in many places *before* > code is written. > > Building community is hard work that you have to intend to do. If you > don't do the work, it won't just happen any more than code writes itself. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
