[looping in groff@gnu to illuminate project management considerations, and to note a facility I had overlooked but could have recently used]
At 2025-09-10T00:51:44+0900, Koichi Murase wrote: > 2025年9月10日(水) 0:38 G. Branden Robinson <g.branden.robin...@gmail.com>: > > At 2025-09-09T10:54:29-0400, Chet Ramey wrote: > > > Being a contributor means being one of the developers: "Type below > > > the name of the group you want to contribute to. Joining a group > > > means getting write access to the repositories of the group, and > > > involves responsibilities." > > > > Can you share a link to where you see that? > > https://savannah.gnu.org/my/groups.php?words=The%20GNU%20Bourne-Again%20SHell Aha! Thanks! I was familiar with this screen but never bothered to read the "Request for Inclusion" box because all I ever interact with is the "Groups I'm administrator of" box--inattentional blindness. This is helpful, and it's where I should have steered our aspiring group member to. > Questions are what qualifies a person to become the group member and > what level of the responsibilities is expected from the group members. I can't answer this for Chet/bash, but for groff, commit privileges attach to this status--I believe it's how I got mine, but I could be wrong, because that would have been Savannah as it was over 7 years ago. > For example, if I become a member, am I expected to be available for > responding or fixing reported issues? For groff, the answer is "yes", within one's domain of expertise. For instance, we have one group member whose sole concern is the "mom" macro package (and who expects other members to keep their hands off of it, with some exceptions for test scripts and other auxiliary stuff that isn't the "meat" of the component), and another who focuses mainly on PDF-related issues. The maintenance of these boundaries is purely social; as far as I know, all group members can create (or delete) Git branches at will, and can commit to any branch at any time.[1] Personally, and for the groff project, I expect any group member to field any ticket as they see fit. There are seldom, if ever, conflicts over "ownership" of an issue, but we do occasionally have technical arguments (usually in Savannah ticket comments that then are mirrored to the "bug-groff" mailing list) about the nature of a problem or the shape of its best solution, as any engineering/development team will. Chet's practices for bash and readline observably differ from mine for groff in some respects; he's been doing his job far longer than I have mine, and since before Savannah even existed. I'm glad Savannah is sufficiently flexible to meet the needs of projects with different management styles and practices, but flexibility can result in under-documentation of what a project's management practices actually are. I recently successfully petitioned the admins/developers to make the properties of bug reports/Savannah tickets less opaque, which should help people to correctly classify issues and illuminate their dispositions. https://savannah.nongnu.org/support/?111303 Regards, Branden [1] I've been frustrated with Savannah's support for Git branches; all branch commit activity is mirrored to the "groff-commit" mailing list, which makes rebases punitively noisy, and force-pushing is not allowed. Together those make Git's branch feature pretty much useless to me. Fortunately we try to keep the "master" branch "green", and now have over 270 automated tests to help us ensure that it stays that way.
signature.asc
Description: PGP signature
