This was actually a worthwhile read, sharing the section titles in case anyone is wondering what they are getting into:<p><pre><code> Lesson 1: Respond instantly
Lesson 2: Early communication is essential
Lesson 3: Treat contributors like team members
Lesson 4: Age reports keep you honest
Lesson 5: Burndown is a must
Lesson 6: Consistency is the name of the game
Lesson 7: Documentation is king</code></pre>
I was skeptical when the author implied automation was the solution.<p>But actually, the given solutions are mostly communication-focused, and the automation is to aid in that.<p>Good read.
A question for people here saying "use a monorepo", and coming from a different direction than that of the article. Say I want to use a monorepo for all code I write for personal use and development, but I'll have a folder with dozens of projects cloned from github often with small tweaks and custom branches. Is the solution submodules? Saving patches or just code-snippets in the monorepo and keeping the random misc repos isolated? Hardlink specific files of interest?
Steampipes is amazing. It is a light in the darkness to anyone taking on enterprise compliance reporting. The growth of the platform laterally
WRT plugins and features while somehow making cross-org/multi-account even easier for end-users on top of building a cloud-hosted solution for teams is a testament to everything in this article.
Another question worth asking is whether 200 repos are worth it. Wouldn't it not be more efficient for everyone involved to merge them all in a single mono-repo?<p>That said, the tips is that article are equally valid for single repositories.
Using 200 repos is just creating unnecessary problems. Use a monorepo.<p>That said, all the solutions are applicable irrespective of how many repos you have. First I'd heard of an "age report" too. I like that idea. It's too easy for bugs to be marked low priority and then <i>never</i> get fixed.
The blog post contains very valuable advices!<p>I'd recommend also shrinking the number of repositories - this can significantly reduce the amounts of efforts needed to sync changes, which span multiple repositories. Ideally there should be a monorepo, where any change can be put in a single atomic commit, even if it touches the core part of the code, which is used in thousands places of the rest of the code.<p>Another recommendation is to keep user docs in the same repository as the code - then docs can be updated synchronously with the code in a single commit.<p>We at VictoriaMetrics are following most of the recommendations from the blog post, plus we try minimizing the number of repositories in order to reduce maintenance burden as described above.
A little late to the reply here but I'm a volunteer for openlibrary.org and I think they'd benefit from trying some of these things so I might share it with you.<p>What tool are you using to make the age reports?
How do you determine if it's waiting on the submitter or the reviewer? Is it based on last comment? or requesting a review, etc?<p>There once was a tool similar to this that github bought and it was quite nice even for a small internal team but I'd really like to know what works well at your scale.<p>Cheers!
As a maintainer I feel like the first tip is not the best approach sometimes. People tend to raise a lot of “I got a problem” issues (well, we all do sometimes) which they solve themselves in a short time (e.g. a misconfiguration). Responding instantly to such sounds inefficient.
In addition to this communication guidance, I prefer when issues are disabled entirely. I would like it to be the default.<p>I am also looking forward to seeing LLMs applied to this space.<p>Plenty of problems could be solved with some simple research and understanding of the code in a project. If that could act as a barrier between those with issues and those who contribute, I imagine it would help a lot.