> I doubt many people are interested in building software for internal use. Look at Pony Mail
I think this nails it as the root cause of the problem. This is always the thing where people expect the "common infrastructure tool" to "just work" - when it does, they have absolutely no reason to learn and be more involved with, but when it stops working, it's very difficult to get engaged and understand how to help, because you have to overcome the first few obstacles: a) where is the repo in the first place? b) do I know the technology stack ? c) how do I build the project ? d) how do I unit test it ? e) how do I make sure things get deployed in a way the whole ASF is not impacted heavily (this one is a REALLY big blocker) ? f) is there a good "contributing guide" I can follow g) whom can I ask if I have a question / am stuck? h) can I be sure to get answers quickly when I ask for help (because otherwise I might get quickly discouraged) ? All that is usually maintained when you have a project when there are many regularly engaged people and they "want" to get more contributions. But when it comes to such infrastructure projects - at some point they reach a "stable" state where problems happen rarely (which is always the case when such a tool is generally doing its job well), and the a) - h) obstacles make people not even think they could volunteer and help. And this is where Rich's comment is very right "we should get more people involved regularly" - but it does not look like we have a good idea on how to do it and most importantly people who "know" about the tools do not do it proactively. Thinking that it will "just happen if we complain we need it, is a bit of a magic way of thinking. As a constructive comment - I can share my own experiences with our CI in Airflow. For a long time (years) I was the only person that knew how it worked, and getting anyone else to help was next to impossible. When something broke the most engagement I could have was "this does not work, I am blocked" kind of response. Very similar to that one. And it became a big problem after some time, I also learned (from Rich I think in one of the messages I saw) that the most important thing as a maintainer is to make sure there is a succession plan in place and that you engage others. So I took it in my own hands - and turned my efforts from "fixing it" into "planning succession and guiding others" - I largely stopped fixing things, I explicitly reached out for help on our devlist and "dev call" discussions we had for Airflow 3 and I got 5 (!) volunteers who were eager to help (but did not know how to start). I used the targeted sponsorship money we had from Bloomberg to organize in-person workshop [1] after our in-person Airflow Summit (including a very nice breakfast) where we sat together and went through the first initial hoops, I explained people how things work, responded to questions and generally made sure they are set for success - and I went for 2 weeks holidays and announced "no communication with me". I also turned the problems I knew into well described and organized issues to work on [2]. We also got a slack channel where we invited everyone interested and started discussing some issues. It worked miracles. Not only those people got engaged and eagerly fixed some of those, but also others got engaged - and got help from those people I "trained" - so we now have a much bigger team of people actively looking and contributing there - and rather than fixing problems myself, I rather encourage and help them to handle those problems. I only "do stuff" when things get really complex - but even then I spend more time on explaining what's going on to others and getting feedback on my proposed changes, than on the changes themselves. But I also make sure I am there now after holidays to help and guide them for the more complex stuff - and that sped up things and got those people engaged even more. If you ask me - this is the absolutely most important task for a person that we hire as the "tools" person. There is no way such a person can single-handedly handle all the tools we have. This is a bit of a dream-pipe if we think this will happen, and for such a person that would be a straight recipe for burn-out if they are tasked with "fixing all the problems the ASF has with the tools". Their role should not be to fix things, but organize the work and make sure they are engaging and actively reaching and finding creative ways of making ASF people contribute. Make sure that the guides are there, make sure the people are enthused and invited, finding a way to do so. Which I sincerely hope is going to happen. Keeping fingers crossed for getting the funding (I know things are progressing there) as well as for choosing/finding the right person and setting it for success with expectations for the person. [1] The CI/CD "knowledge transfer" meeting - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=321718991 [2] "CI / CD planned work" Github project - https://github.com/orgs/apache/projects/403 J. On Sun, Oct 13, 2024 at 3:26 PM Christian Grobmeier <grobme...@apache.org> wrote: > Probably this it a case for the new VP tooling? > I doubt many people are interested in building software for internal use. > Look at Pony Mail > > -- > The Apache Software Foundation > V.P., Data Privacy > > On Sun, Oct 13, 2024, at 15:17, Mark Struberg wrote: > > Hi Rich! > > > > I totally understand that notion.But there is apparently not exactly > > much to contribute tohttps://github.com/apache/comdev-reporter > > After some time of digging I found that the sources are still > > maintained > > inhttps://svn.apache.org/viewvc/comdev/reporter.apache.org/trunkbut > > apparently the sync to git doesn't work? > > > > There are people like me who already contribute to about a dozen ASF > > projects.And yes, I'm also willing to help out with one more IF I know > > the technology stack. Means if it's programmed in some language I'm > > fluent (Java and C, C++ mostly). Trying to dig into it, but I'm not > > sure if I'm much of a help in that mixture of js and python. And I've > > not the slightest clue about that kibble tool yet. > > > > LieGrue,strub > > > > > > > > On Sunday, 13 October 2024 at 14:54:37 CEST, Rich Bowen > > <rbo...@rcbowen.com> wrote: > > > > On Sun, Oct 13, 2024, 5:32 AM Mark Struberg <strub...@yahoo.de.invalid> > > wrote: > > > >> Hi! > >> > >> It seems that the commit statistics on the reporter.a.o pages do not > work > >> anymore? > >> https://reporter.apache.org/wizard/statistics?openjpa > >> and > >> https://reporter.apache.org/wizard/statistics?openwebbeans > >> > >> show zero commits but this is actually not true. > >> Is there anything on our side we can do? > >> > > > > I feel like the most important thing we can do is get more people towards > > an understanding of how the reporter tool works so that it's not just on > > one or two individuals to resuscitate it when things go down. > > > > Perhaps what we need is more visibility into the fact that this is a > > volunteer driven tool and that contributions are welcome from everyone. > In > > the long ago, projects would pitch in to infrastructure stuff that was > not > > officially supported and this kind of falls into that same category. > > > > My impression is that almost every time this happens with reporter, the > fix > > is quick and easy, but that only a handful of people know how to do it. > Can > > we try to spread that knowledge a little bit? > > > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
