"G. Branden Robinson" <g.branden.robin...@gmail.com> writes:
>> 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. Unless there is something I do not know about, being a member of the group always gives commit privileges. >> 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 would prefer that groups are kept to only members who actually push commits. Otherwise it opens things up to malicious actors. Both yours and Chet's style work equally well, in my opinion. Collin
