On Saturday, July 4, 2020 at 1:34:50 PM UTC+7, Martin Blais wrote: > > Hi, > Today I'm starting development on Beancount v3. >
I'm excited to see (hopefully, fingers crossed!) more active development on beancount restarting. Even though performance hasn't been an issue for me and beancount works for 99% of my use cases, there's still lots of good ideas for improvements out there. My comments here focus on trying to increase the size of the contributors that you mention in the document, though I have a feeling the earliest days of a rewrite isn't really the best time to push for dramatic increases in contributors. As you identify, the biggest problem facing beancount from a project management perspective is "Martin doesn't have enough hours". So I was thinking...what are things I'd do in my professional life when faced with that situation. Usually it involves some combination of delegation to others with important issues bubbling up for "sign off", high-level summary/reporting, and semi-regular synchronous check-ins. Which of those can we adapt to beancount? The overall general idea is to increase the cadence of activity by having more eyes & voices via devolved & limited kinds of authority while Martin builds up confidence in "lieutenants" before graduating to full-on BDFL. Here's are some half-baked ideas: * Have a "bugmaster". This is a community member who isn't even necessarily that acquainted with the code base (perhaps not even technical at all) but they are engaged with the project and can help reply to new bug reports quickly and triage them. Close duplicates, ask for more information & reproduction steps quickly (i.e. while the reporter is still paying attention), and help bring important issues to the attention of Martin & other people doing development. * Have "code reviewers" who do not (yet) have commit rights. Looking over new PRs, pointing out better ways to utilize the APIs, or even collaborating on adding tests. The idea is to reduce the amount of effort Martin has to do to accept PRs and provide a stepping stone for contributors to full-write contributions trust levels. * Make providing tests a "two-stage commit". As Martin rightly notes, providing tests is important in any long-lived project. But it also works against the "first time contributor rush" of having a PR accepted. Are there way we can convert more of those contributors and get them more engaged? Can we accept the original PR but track that tests need to be added, either by the original contributor in a subsequent PR or by another contributor. Of course, this runs the that "core contributors" do nothing but writes tests for other people. I said my thoughts were only half-baked! * Martin mentions "monthly team meetings" which I think is a good idea -- it provides a synchronization point for things like the bugmaster or the code reviewer to agitate for action on something that seems to have been stalled. Though I'm less sure about the exact style & format. Monthly versus quarterly? Zoom video style versus Discord text style? I think we'd have to see some proposed agendas of what such a team meeting might be about to say much more. -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/fec1427e-cfa6-4451-81f8-38ae08bae476o%40googlegroups.com.
