Hey Mike, Thanks for sharing, it is helpful to hear the experience that leads to these recommendations.
-Jay On Mon, Jul 13, 2015 at 11:01 AM, Mike Kienenberger <mkien...@gmail.com> wrote: > A subproject is one of many projects that fall under the same umbrella > project management committee (PMC). It doesn't have to be a separate > repo, but it generally has a separate community or a subset of the > full community. > > Speaking as a long-time PMC member for MyFaces, our problem with > subprojects (we have 11!) is that it's hard to keep accountability and > monitor community health. > > A subproject starts of being active with some subset of the community, > but then reduces activity at some future point. Those who aren't > directly involved with the subproject tend not to notice that the > particular subproject has fallen to unhealthy levels. Generally, you > don't realize something is wrong until after all of the developers > have left when you suddenly realize that there's no one answering > questions, applying patches, or familiar with the code base. > > Non-umbrella projects report to the board are expected to evaluate > community health each quarter. Umbrella projects are also supposed > to do this, but often fail to realize that community health has to be > individually evaluated for each subproject each quarter. The PMC > chair is likely not directly involved with each subproject, and may > not be in a good position to evaluate the sub-project's health. As > Hervé mentions, this is particularly true for TLPs which have a main > project and "optional" modules where everyone cares about the main > project and only a few care about each module subproject. This is > what happened with MyFaces. > > What tends to happen with umbrella projects is that you end up > creating two-tier project management. Those responsible to the board > are "upper management" but may not be directly involved and fail to > understand the subproject community health. Those who are supposed to > actively manage the project are "lower management" and are not > directly responsible to the board for quarterly reports. > > Best practice is to have a one-tier PMC. As soon as a subproject is > healthy enough to stand on its own, it probably should go TLP. > MyFaces successfully spun off DeltaSpike, and DeltaSpike remains > healthy. The other alternative is to be certain to address the status > of each subproject in the board report, much like the Incubator board > report does each time. > > My advice is the same as others -- keep the two projects separate, but > encourage individual Samza committers join as Kafka committers if they > feel the need to do so. > > On Mon, Jul 13, 2015 at 1:37 AM, Jay Kreps <jay.kr...@gmail.com> wrote: > > Hey board members, > > > > There is a longish thread on the Apache Samza mailing list on the > > relationship between Kafka and Samza and whether they wouldn't make a lot > > more sense as a single project. This raised some questions I was hoping > to > > get advice on. > > > > Discussion thread (warning: super long, I attempt to summarize relevant > bits > > below): > > > http://mail-archives.apache.org/mod_mbox/samza-dev/201507.mbox/%3ccabyby7d_-jcxj7fizsjuebjedgbep33flyx3nrozt0yeox9...@mail.gmail.com%3E > > > > Anyhow, some people thought "Apache has lot's of sub-projects, that > would be > > a graceful way to step in the right direction". At that point others > popped > > up and said, "sub-projects are discouraged by the board". > > > > I'm not sure if we understand technically what a subproject is, but I > think > > it means a second repo/committership under the same PMC. > > > > A few questions: > > - Is that what a sub-project is? > > - Are they discouraged? If so, why? > > - Assuming it makes sense in this case what is the process for making > one? > > - Putting aside sub-projects as a mechanism what are examples where > > communities merged successfully? We were pointed towards Lucene/SOLR. Are > > there others? > > > > Relevant background info: > > - Samza depends on Kafka, but not vice versa > > - There is some overlap in committers but not extensive (3/11 Samza > > committers are also Kafka committers) > > > > Thanks for the advice! > > > > -Jay > > > > > > >
