Defining Bitcoin Design Community Maintainers

[moneyball]

We need to decide the maintainer role and who the initial maintainers are. I would like to see the community discuss the following 3 questions:

1. What is the maintainer role?
2. What is the criteria to be a maintainer?
3. How are maintainers chosen?

To start things off, I'll provide some of my own thoughts.

The role:

• What it literally means is to have GitHub permissions to merge changes. This would include changes to the website and changes to the bitcoin design guide. However...
• A maintainer should adhere to rough consensus. The decision to merge should not be based on personal preference but instead rough consensus: whether the maintainer in their judgment feels like those involved with the change have provided proper motivation for it, that other community members have had a fair opportunity to voice concerns, and that no genuine concern has gone unaddressed.

The criteria:
A commitment to FOSS bitcoin and specifically this bitcoin design community. Demonstration of this can include

1. First, obviously, is a personal and public statement by the individual saying they're committed to the community and to uphold the duties of the role.
2. Historical FOSS bitcoin contribution, track record, and reputation
3. Current engagement and activity with the bitcoin design community. Is the person regularly available? Reliable? Have they consistently participated in discussions on GitHub? On Slack? On community or other video calls?
4. Judgment. Does the person exercise good judgment when it comes to deciding which changes to merge and not to merge. Is it consistent with rough consensus, with community precedent, and in the spirit of the community?

How are maintainers chosen?
This is a bit tricky when starting a new community. It is easier when a community is many years old, because there is more evidence and track record for a consistent contributor and demonstration of exercising good judgment. But, we need to start with at least 1 maintainer or else nothing will ever be merged :)

I think we should lean toward starting with fewer maintainers. That allows us to provide more time for others to demonstrate the criteria stated above. Also, we should feel the need for more maintainers before adding more. My gut tells me to start with 2 or 3 at the beginning.

What do others think?

[GBKS]

There's some good general reading on this topic on Githubs open source guides. I think it's important to also understand the roles of user, contributor and committer in relation to that of the maintainer (at least for me, it has been helpful to do some reading). A maintainer really just helps make the final call in a longer process of collaboration. During that process, the role itself doesn't give extra formal influence. So I don't see it as a "glamorous" role.

I would also prefer starting with a smaller group. It's not like we even have that much code to merge at the moment. Maintainers don't block discussion, work on contributions or work-in-progress review, so might as well only scale that role as needed.

I like the four criteria.

One thing to clarify would be the practical steps in how somebody becomes a maintainer. I assume they can either request it, or current maintainers ask the person?

[johnsBeharry]

The Role

1. Would these maintainers have to perform reviews across all repos? Or would it be more specific to the one/s they may have the most interest in?
2. I would imagine the role may also extend reviews to documenting processes, and FAQs (but only on GitHub or does this also include slack?).
3. As @moneyball stated there should be at least a minimum of 2, as the maintainers need to have their own PRs reviewed, and not directly commit to master. Also in the event one is unavailable, 3 seems to be the magic number.

The Criteria

1. The technical requirements may exclude some less technical persons who may otherwise be enthusiastic about performing maintenance. Not sure what else we can do to resolve this other than encourage more designers to learn git/github I just thought I should mention that point.

[moneyball]

Maintainers do not need to review all changes. They can rely on other reviewers. Of course, they're welcome to review any change to whatever degree they wish.

It isn't clear to me why (a) git/github expertise is important in this role (b) why every community member cannot learn how to use github web interface to explain their change, comment on other changes, etc. It is a very basic web tool. Related, there is NO requirement to use github for any design work. Community members can use Figma, Sketch, whatever tool to do their design work. Just link it from the GitHub Issue/PR.

[johnsBeharry]

Scenario: Malicious script disguised as content

• Malroy creates a PR with some malicious script in <iframe w=1 h=1 src="figma-com.com"> in BitcoinDesign/Guide, along with some content changes that are visible.
• Malroy gets some number of ACKs or 👍💯 in slack after sharing a link to the staged content
• After some time has passed, the Maintainer feels its fine to merge the change, as there have been no NACKs

☝️ A question that arises in the above scenario is how much weight is put on Slack vs that on GitHub in the review process since we use both platforms to solicit feedback.

Scenario: Malicious script added to build process or website code

• In this scenario it could be that PRs are labeled "content" or "code" and those with "code" must be reviewed by someone technical. The rule for "content" changes should be that ONLY .md files in the change list.

[moneyball]

I think only (N)ACKs on GitHub should be considered. Also clearly the username of the GitHub accounts should be considered based on their past contributions and areas of expertise. And of course the quality of comments/review content should be considered.

…

On Sat, Aug 22, 2020 at 10:16 AM Johns Beharry ***@***.***> wrote: Scenario: Malicious script disguised as content - Malroy creates a PR with some malicious script in <iframe w=1 h=1 src="figma-com.com"> in BitcoinDesign/Guide, along with some content changes that are visible. - Malroy gets some number of ACKs or 👍💯 in slack after sharing a link to the staged content - After some time has passed, the Maintainer feels its fine to merge the change, as there have been no NACKs ☝️ A question that arises in the above scenario is how much weight is put on Slack vs that on GitHub in the review process since we use both platforms to solicit feedback Scenario: Malicious script added to build process or website code - In this scenario it could be that PRs are labeled "content" or "code" and those with "code" must be reviewed by someone technical. The rule for "content" changes should be that ONLY .md files in the change list. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACPUA56L6X5SF2B7K7CVVDSB74PXANCNFSM4QGVIZOA> .

[moneyball]

@GBKS thanks for that doc reference. Something I read there that I think is important for the maintainer role is "someone who feels responsibility over the direction of the project and is committed to improving it."

[ConorOkus]

I think it's also important that maintainers are only responsible for one aspect/concern of the project

• Domain Maintainer - much discussion being had on this here
• Github Maintainer - some responsibilities outlined in the opening comments of this issue
• Devops/Deployment maintainer - responsibilities would include, releasing, setting up staging & PR builds, rolling back etc
• Figma Maintainer?

[danielnordh]

I agree with Steve's definitions of a maintainer.
Would suggest that we start with 3 maintainers for Github.

[moneyball]

A few additional questions I've received that I thought I'd share my take more widely:

Q: Is the maintainer expected to establish the process of reviewing?

A: No. The process is established and documented here: https://github.com/BitcoinDesign/Meta/blob/master/Projects.md. Improvements to this process can be suggested by any contributor. Maintainers should ensure this process is followed, although all contributors should feel welcome to ensure the process if followed.

Q: How are the changes on something other than on GitHub being reviewed? eg. Designers contributing on Figma.

A: I don't think maintainers need to specialize in every design tool that exists. Contributors are welcome to use any tool they wish, and there can be discussion and debate within that tool (such as Figma), but ultimately for a change to get accepted and merged, it needs to have sufficient review and ACKs on the relevant GitHub PR and without valid NACKs. The maintainer should ensure that is present.

Q: Is each maintainer dedicate to a specific repo? Will the maintainer who merge the changes of design guide also able to merge for the website?

A: Maintainers would be generalists. If we need to specialize over time we will. So, any maintainer would have merge access to both repos, but there wouldn't necessarily be an expectation that each maintainer has to be equally active in both repos. As long as we have sufficient total coverage we're good.

Q: What are some guidelines to ensure the objectivity?

A: The community is the best counterbalance to this. For example, if a contributor sees a maintainer merge something that didn't feel right to them based on other ACKs/NACKs/comments, then they'd reach out privately and ask about it. Others might call it out publicly.

Q: Does it have to be a consistent time? Checking once a day? Once a week?

A: We would want to make sure the pace of the project is good and that the set of maintainers are not a bottleneck. But, there would be more than one maintainer, so, an individual maintainer could go on vacation for a week, move for a week, have a health issue, etc. and the system wouldn't break down. So certainly things like that in life can be absorbed and accommodated. However, if over the span of 6 months a maintainer is not available for 3+ of those 6 months, that probably isn't the kind of reliability we're looking for.

[Bosch-0]

Q: How are the changes on something other than on GitHub being reviewed? eg. Designers contributing on Figma.

Just my 2c on this and something I'm exploring with Bitcoin Core is having a 'Bitcoin Core' Figma account (here is an example of an entity based figma account) that manages a set of master pages that include things like a style guide, designer workflows, current active designs, icons, components, community contributed art etc.

Community members can create a remix (figma community feature) of these master pages to use as a reference and work on their own designs. This kind of acts like a GitHub 'branch' of the master page. Remixs of pages are shown under the master page (see here) so if someone wants to see what community members are working on they can browse through the various remix's.

This account would have a maintainer(s) who can update the master pages as needed. An issue with this approach is it is hard to keep track of what is updated (version control isn't that great, paid Figma does it better, need to explore this further though) and when and by who (maintainers could change what they want at will). Everyone would have their own 'fork' (in the form of a remix) though so if anything major changed community members could speak out and switch to the appropriate 'fork' if a consensus is met. Where this discussion happens would ideally be within a GitHub repo that is dedicated to the figma master account as to not divide designer and developer input.

I'm still fleshing out this concept - any input would be much appreciated.

[Bosch-0]

Here is a visual

Figma source

[GBKS]

This issue has been inactive for over a year. Now that we have experience with the community and maintaining things, is there anything you want to discuss or change?

[Bosch-0]

Let's create a CoreMaintainers.md file in this repo that summarises the discussion above and also lists who said core maintainers are. I think currently it is a little ambiguous who are the core maintainers atm though I would say they are:

• Christoph
• Pavlenex
• Johns
• Stephen
• Myself
• @ConorOkus ? I put a question mark as I know Spiral wanted to disassociate from the community as to not be perceived as directing things. Conor has been around prior to working at Spiral so idm either way.

I'd also suggest pinning a post to the General channel in Slack listing the Core maintainers for added transparency.

[ConorOkus]

Disassociate is probably the wrong word, we love the community! 😄

But yeah we want to reduce our influence as much as possible and encourage funding from multiple sources. I think you should remove me as a maintainer 👍

[pavlenex]

I'm happy to be on a maintainer list, though I wouldn't mind a more active member to take over my spot once we identify such a member. 👍

[danielnordh]

Two slightly separate issues here:

1. Define and publish what the role of the maintainer is --> the coremaintainers.md mentioned by @Bosch-0
2. Change maintainers as defined by this list, IF REQUIRED

For 1
This is the more important of the two IMO.
The very first post in this issue, followed by the response from @GBKS to me summarizes 90% of what the role means.

I think it's important to also understand the roles of user, contributor and committer in relation to that of the maintainer (at least for me, it has been helpful to do some reading). A maintainer really just helps make the final call in a longer process of collaboration. During that process, the role itself doesn't give extra formal influence. So I don't see it as a "glamorous" role.

Making the maintainer role come with some form of practical responsibility makes sense to me. I.e, the list of GitHub owners equal the maintainers.

In the .md file we could also outline; an ideal range of maintainers, how often it should be reviewed, some reasons for adding/removing people, whether there should be a fixed limit on terms etc. My suggestions:

• Number of maintainers: minimum 3, no more than 5
• Review frequency: maximum one year intervals
• Reasons for removing people: They want to withdraw, Irresponsible behavior as deemed by a majority of others, Unresponsiveness in critical situations etc.
• Reasons for adding people: The number of maintainers would otherwise fall below 3, ...?
• Term limits: No, long term stability is good

For 2
I have not experienced any issues with the current list of maintainers. BUT I think it is healthy and good to periodically review and adjust if necessary. This is probably also an issue that should receive broader input if changes are being made.

• Do we feel the need to REMOVE anyone from the list (or does anyone want to be removed)?
• Do we feel the need to ADD anyone to the list?

I am currently on the list. I don't feel the need to withdraw, but am also happy to give up my spot if required.

[sbddesign]

• Yes, let's define the roles of the maintainer in a coremaintainers.md.
• I also like the idea of having the maintainers tied to the BitcoinDesign GitHub organization.
• Agree generally with everything Daniel is saying

I have consolidated some of what I am seeing in these comments into a draft file. Perhaps we should collaborate on this document together, and then create a markdown file and PR once we've gotten closer to consensus in the Google Doc. Document is open to comments by all, and happy to give edit access to those who request it.

Core Maintainers Early Rough Draft