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
