I think a big and simple thing to consider is that the difference between success/failure in migrating to Apache TLP is one of attitude -- i.e., the very same things that the Zipkin community considered to be immensely frustrating were considered to be immensely frustrating to the NetBeans community too. However, in the case of the NetBeans community we (1) didn't have the pre-history of going it alone that Zipkin has, i.e., for Zipkin there was always the possibility of going back to their independent status before Apache, while for NetBeans the prior state was Oracle and NetBeans couldn't go back, it simply needed a governance model and so if it wasn't going to be Apache it would have been something else, which would have been frustrating to get into as well, so we just simply persevered until we adopted everything and accepted everything and (2) Zipkin seems to be less cohesive than NetBeans and less interested in being cohesive, i.e., concerned about laying down things for subgroups that might be averse to that, while NetBeans is a pretty holistic organism working towards very similar end goals. So, it's as much the nature of the specifics of a community or project as it is about the specifics of Apache, the Apache Way, the Incubator, etc.
Gj On Mon, Jun 17, 2019 at 7:26 PM Dave Fisher <dave2w...@comcast.net> wrote: > Hi Roman, > > All very true. What the Incubator could do better is to let people know > the key values of The Apache Way that will impact any existing community if > they come to the ASF through the Incubator. While it will be a community > that comes (or doesn’t), it will more likely be a vendor than a community > that decides to come to Apache. That will more likely be for the permissive > licensing than for community over code. > > (1) The careful Apache Licensing and Release process that is not fully > automated might be a surprise. If a project relies on frequent and quick > releases then there will be a cultural issue as the project adapts. This > needs to be fully considered. Projects need to discuss a more careful and > deliberate transition between existing process and the ASF. Moving over > repositories immediately might not be best. > > Yes, the IPMC can help lower the impedance for a release. I think rather > than parallel releases we should allow projects whose communities need > faster releases to be slower about moving repositories to Apache. > > (2) Community over code means global asynchronous communications with > decisions in public based on Consensus. Consensus is often simple (Lazy), > but is sometimes very difficult. This is the opposite from a “king” or BFDL > (aka Linux Kernel, etc.) and it is not driven from within a “Vendor” team > (at least not in the end.) The very foundation of the Apache Group was to > bring back an abandoned project. An Apache project with a functioning PMC > replaces committers from the community and supports the community of users. > In many PMCs the original developers are long gone and some are likely in a > fourth or fifth generation of committers. > > I think that the IPMC should recommend that mailing list communications be > fully established prior to moving repositories. Rather than having the > quickest most active developer take charge immediately we get Consensus > from all the Initial Committers about it being time to move a repository. > The choice of Transferring vs. Cloning needs to be clearly made. > > Surprises with repositories include giving up some admin rights and > plugins in GitHub due to Apache’s management of 100s of repositories (close > to 1000?) This will impact a project’s pipelines in unexpected ways. > > (3) Coming to Apache does mean there is a unique view on Foundation > available resources. If a project wishes to Incubate with a number of extra > resources then careful planning and possible exceptions to policies will > need to be negotiated. > > I could go on, but I think we need to identify for prospective podlings > what the main cultural points are so that they can know if they will have > trouble. > > I think that the podling proposal template should be updated to be less > verbose and more about the podling community clearly understanding what its > going to happen and identifying what support the community will need. > > Regards, > Dave > > > On Jun 17, 2019, at 9:02 AM, Roman Shaposhnik <ro...@shaposhnik.org> > wrote: > > > > On Mon, Jun 17, 2019 at 8:51 AM Geertjan Wielenga <geert...@apache.org> > wrote: > >> > >> It’s not really totally OK. People leaving back to their old place > feeling > >> unhappy and frustrated, how is that totally OK? > > > > I'll stick with Christofer's analogy -- if you come to a new country > > thinking that > > the roads are paved with gold -- all you're going to get is > > frustration and unhappiness. > > Not a single place is a paradise on earth. > > > > If, however, you come to the new country with the intent to learn and > > see if this > > place can *gradually* become your new home -- now you're talking. > > > > Obviously, this doesn't apply to refugees (I guess in our world it > > would be corporate > > refugees) but it applies extremely well to everyone else. > > > >> How positive is that departing community going to be about Apache? Is > that really totally OK? > > > > I'm not sure if you fully realize this, but Apache is a TERRIBLE place > > for a whole > > bunch of communities (I could totally see this being misquoted -- but > > I'm doing it on purpose). > > > > ASF is a HORRIBLE place to run Linux Kernel community. ASF is a > > HORRIBLE place to > > run any of the corporate-centric ASF communities, the list goes on. > > > > What we should aspire to is that, on balance, we're an excellent place > > for the kinds of > > communities that have an affinity to our governance model (and > > license) but that's > > about it. > > > >> I think it’s a sign that there was something wrong in the pre-incubation > >> discussions, certainly some misconceptions. Sure, it’s not the end of > the > >> world to go back to the old place, but certainly not the ideal either. > > > > There's as much wrong about pre-incubation as it is with trying to guess > whether > > you'd feel at home in a country by looking at travel shows on TV. > > > > Thanks, > > Roman. > > > > > >> On Mon, 17 Jun 2019 at 17:36, Roman Shaposhnik <ro...@shaposhnik.org> > wrote: > >> > >>> On Mon, Jun 17, 2019 at 1:24 AM Christofer Dutz > >>> <christofer.d...@c-ware.de> wrote: > >>>> > >>>> Hi Geertjan, > >>>> > >>>> not quite sure how to read this ... what are you referring to as "new > >>> culture". > >>>> The existing project coming to the ASF? And this project should adopt > >>> the tradition of the ASF. > >>>> Or that the ASF should adopt the culture and tradition of the project > >>> joining? > >>>> (Probably then meant more as: Allowing them to continue than the ASF > to > >>> change) > >>>> > >>>> I think projects coming to the ASF have to be educated prior to > entering > >>> incubation that > >>>> there will almost always be things we are expecting them to change > when > >>> they come to Apache > >>>> and that there's no discussion on if they have to follow them. > >>> > >>> This! Also, I think we should stop being so uptight about communities > >>> trying incubation > >>> and deciding that ASF is not for them. It is a two-ways street when it > >>> comes to education. > >>> > >>>> We have to make them understand that the ASF is more than a GIT repo, > CI > >>> Server and Mailing lists. > >>>> That the ASF has great things to provide (Legal Shield, Marketing, > >>> Infra, ...) but that this only works > >>>> If you play along with some rules we have. Also should we explain WHY > >>> these rules are there. > >>>> > >>>> I would say it's sort of like emigrating to another country: You > >>> probably move for some reasons. > >>>> But also probably the rules are a little different at the country you > >>> are moving. There will be things > >>>> You will be allowed to do the same way you always did it, but there > will > >>> be things expected of you > >>>> to simply follow and not ignore, because you think otherwise. > >>> > >>> And sometimes you'd return back to your old place after all -- and > >>> that's totally OK. > >>> > >>> Thanks, > >>> Roman. > >>> > >>>> We have to find a way to state the rules and what we expect before > >>> podlings enter incubation. > >>>> > >>>> Still we will have podlings that sort of remind me of small children > >>> simply not willing to do something simple, > >>>> Just cause a parent told them to: "No, I will not say thank you". > >>>> > >>>> Or converted to our world: "No, I will not add anything to any > Notice", > >>> or "No, I will not credit stuff I > >>>> obviously borrowed somewhere" ... but this way we can always refer to > >>> the rules being clearly > >>>> communicated prior to entering incubation and not have to listen to > >>> complaints all the time. > >>>> > >>>> And for my point of view: If there are projects, that join the ASF, > but > >>> don't want to play according to the > >>>> Rules - we're off way better without them. At least I don't want to > >>> invest my time (which is already > >>>> Spread out pretty thin with all the things I do for the ASF) to deal > >>> with rebellious podlings. > >>>> > >>>> Chris > >>>> > >>>> > >>>> > >>>> > >>>> Perhaps creating a training session as part of the training podling > >>>> > >>>> Am 13.06.19, 22:29 schrieb "Geertjan Wielenga" <geert...@apache.org > >: > >>>> > >>>> Speaking on behalf of myself only, though note I am PMC chair of > >>> NetBeans, > >>>> which went through a protracted (nice way of saying ‘complex’) > >>> incubation > >>>> because of its size (‘very large’) and history (20+ years) — the > key > >>> to any > >>>> new culture is to adopt its traditions and to fight them as little > as > >>>> possible. And one can’t really understand the culture until one is > >>> in it. > >>>> It’s hard to really prepare — other than to admire projects like > >>> Maven or > >>>> TomEE and to want and aim to be like them, regardless of the > >>> contortions > >>>> required to get there. > >>>> > >>>> Gj > >>>> > >>>> > >>>> On Thu, 13 Jun 2019 at 21:10, Dave Fisher <dave2w...@comcast.net> > >>> wrote: > >>>> > >>>>> Hi - > >>>>> > >>>>> Here are some thoughts I have to improving Incubation. These are > >>> not > >>>>> really new, but I think we should discuss where and how best to > >>> apply these. > >>>>> > >>>>> (1) Champions need to very clear that the ASF expects Community > >>> decisions > >>>>> not BDFLs. Burnout is one factor to highlight why community is > >>> important. > >>>>> Vendor independence is important and part of why BDFLs don’t fly. > >>> In the > >>>>> last few years we have deemphasized the role of Champion and I > >>> think we > >>>>> need to list out some of the duties a Champion has to both the > >>> prospective > >>>>> podling community and the Incubator. > >>>>> > >>>>> (2) We should help existing communities plan their entry into > >>> Incubation > >>>>> with their proposals. Currently TVM is moving their community over > >>> before > >>>>> repositories. That might be a better approach for many communities > >>> as it > >>>>> will assure that (a) the existing community keeps its current > >>> velocity and > >>>>> (b) they are making community decisions on list before actual > >>> development > >>>>> is moved over. > >>>>> > >>>>> (3) Having a lower impedance to release and code changes would > >>> really > >>>>> help. We are already having this discussion. A very radical idea > >>> might be > >>>>> to move a lot of the License, Notice and Dependency work away from > >>> the > >>>>> Release Vote and instead do periodic and potentially automated > >>> audits of > >>>>> repositories. This would follow the REVIEW suggestion, but make it > >>> more > >>>>> automated and based on tooling. > >>>>> > >>>>> (4) Relinquishing control of admin rights on GitHub repos is an > >>> impedance. > >>>>> I understand why this is done from an Apache Infrastructure > >>> perspective, > >>>>> but it is a surprise to podling communities. Making sure that a > >>> new podling > >>>>> knows fully what to expect before transferring repos would really > >>> help > >>>>> manage expectations. > >>>>> > >>>>> (5) Failure to incubate is not failure. Currently 63 podlings have > >>> retired > >>>>> and there are two or three additional retirements soon. 4 or 5 > >>> podlings > >>>>> moved on or back to where they were. The why of retirement could be > >>>>> analyzed, but it would need to look into mailing list archives > >>> because the > >>>>> information in podlings.xml is not always clear and is sometimes > >>> more > >>>>> diplomatic than the reality. > >>>>> > >>>>> See https://projects.apache.org for an intriguing chart. > >>>>> > >>>>> Regards, > >>>>> Dave > >>>>> > >>>>> > >>>>> > >>>>> > >>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >>>>> For additional commands, e-mail: general-h...@incubator.apache.org > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >>> For additional commands, e-mail: general-h...@incubator.apache.org > >>> > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
