Hello Justus, open source projects evolve and function in very different ways from more structured enterprises. They are often described as do-ocracies: the control is in the hands of those that step up to do things that go in what is perceived to be the direction of the project as a whole. There should be no need to assign official roles for people to do some work as there should not be expectations on what should be the time commitment of anyone involved, Martin included.
Beancount is not in a stage in which there are too many contributions and the bottleneck is the organization of the contributions, but it is a successful project that works well enough for mot people (as recent messages on this mailing list express). On 05/07/2020 00:48, Justus Pendleton wrote: > * 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. Stefano already commented on this and I completely share is doubts on the effectiveness of this. In addition to that I would like to point out that as far as I can tell there are no bugs affecting existing functionality in the bug tracker, but only requests for extended functionality. It is very easy to quickly described what is perceived as a desired feature in a ticket in the bug tracker (or as a few lines patch), however it is not as easy to understand all implications and evaluate the feature in the context of the vision for the project. If someone feels to have a sufficient understanding of the project and of the direction in which it is aimed, nothing prevents they to comment on specific issue or pull request. I do so when I bump something I find interesting (either because it affect my use of Beancount or because I find the problem stimulating). > * 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. We are not swamped into PRs. At the moment there are only three open PRs with important changes to the codebase and they have been open by less than a week (I am the author of all of them). If anyone (especially someone with a deeper knowledge of Flex/Bison than me) wants to comment on them they are welcome, but I don't see PRs review as being the factor that hinders Beancount development. > * 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! Please, no. How is someone expected to evaluate the quality and correctness of a change if there are no tests? Who is going to write the tests for the added functionality? Writing tests requires precise understand if the functionality so it is much easier for the original author to write them. Also, writing tests is not the most fun part of development, I definitely would not spend my free time doing it for features I have not contributed. I actually would go the other way around and require that PRs come also with documentation updates or additions. However this is harder to track with the source of the documentation being in Google Docs. Beancount is a mature project and I don't see the reason to encourage pass-by submission of half backed PRs. This would only increase the burden on the maintainer(s). > * 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. I agree with Stefano here: sprint like meetings (to use the jargon of the Zope community, or hackatons if you prefer) are probably effective in pushing development forward. Other formats may help but it depends on many factors. Face-to-face (virtual or physical) meetings are important to put faces behind messages on the mailing list (or Github tickets or PRs). Because of the human nature, this allows for more effective communication subsequently, but I don't know if a regular meeting with many individuals involved would provide much benefit. Finally, please no proprietary platforms. We are developing a free software project and the tools required for participating should ideally also be free. I don't see the reason to use Zoom or Discord when so many free (as in free speech) exist. Cheers, Dan -- 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/92a4e3d7-642b-b071-36a7-fd05b292db6f%40grinta.net.
