-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Defining Bitcoin Design Community Maintainers #10
Comments
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? |
The Role
The Criteria
|
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. |
Scenario: Malicious script disguised as content
☝️ 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
|
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>
.
|
@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." |
I think it's also important that maintainers are only responsible for one aspect/concern of the project
|
I agree with Steve's definitions of a maintainer. |
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. |
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. |
Here is a visual |
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? |
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:
I'd also suggest pinning a post to the General channel in Slack listing the Core maintainers for added transparency. |
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 👍 |
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. 👍 |
Two slightly separate issues here:
For 1
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:
For 2
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. |
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. |
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:
To start things off, I'll provide some of my own thoughts.
The role:
The criteria:
A commitment to FOSS bitcoin and specifically this bitcoin design community. Demonstration of this can include
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?
The text was updated successfully, but these errors were encountered: