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 > > >
