unifiedjs / collective Goto Github PK

I'd like to nominate @zeke for the @remarkjs team.

Zeke implemented remark in electron/electron, electron/i18n, electronjs.org, and node/i18n through electron/hubdown. I think that makes him a good stakeholder / area expert.

cc: @unifiedjs/core

Remco has been adding to types to @remarkjs, @rehypejs, @syntax-tree, participation that matches that of a contributor, but is (currently) not interested in becoming a maintainer.

See Motion to nominate a contributor for more information.

@unifiedjs/core Please vote

@remcohaszing Can I use your commit-associated email address? Do you have an npm username?

Hi folks! 👋

I’d like to move this project, unifiedjs/governance, to unifiedjs/collective.
The reasoning is that this would allow unifiedjs/governance to be used for the organization team, whereas unifiedjs/collective would be used by the @unifiedjs/core team.
This would allow all organisation teams to have their own governance repository to talk about the things they govern, and give the collective team their own place.

A different issue is that I’d like a unifiedjs/moderation project to exist, governed by the moderation team, I’ll leave that up to @unifiedjs/moderators.

Per GH-29, renaming a project is intentionally undefined, therefore there is no motion, vote, or playbook involved. But I’d like to ask for opinions / feedback anyway!

/cc @unifiedjs/core

I didn't test, but I imagine this affects ALL your npm packages

Seems the hip thing to do is to change repos' primary branches from master to main. But seems your [npm] pages don't reflect those changes, even if their package.json is updated:

https://www.npmjs.com/package/rehype-stringify

No action needed on your part; just posted here to help track.

https://twitter.com/ethomson/status/1281223587546963968

I'd like to nominate @kmck (Keith McKnight) as a member of the @remarkjs, @rehypejs, and @syntax-tree merger teams.

Keith created hast-util-to-dom and hast-util-from-dom, which come together in rehype-dom: rehype, but using browser APIs, so much smaller! Those have since been moved under syntax-tree and rehype respectively.

I think those are really interest projects, and it’s a sign of a good understanding of the ecosystem, so I think Keith is a great addition to triage, review, and help out!

I'd like to nominate @jamesknelson as a member of @mdx-js merger team.

He built MDXC which was an inspirational library when building MDX and is an active community member building tooling that improves the ecosystem.

His thoughts and experience will also be important when we build out interleaving in the library since we will likely closely model it off of the API he designed and implemented in MDXC.

GH today added more visibility to security policies, similar to how they surface a support.md, contributing.md, and code-of-conduct.md: https://github.blog/changelog/2019-05-23-maintainer-security-advisories/

There is now support for a security.md file.

It seems to be possible to add this in a org/.github repo as well.

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

See Motion to nominate a maintainer for more information.

See recent work

See request: https://github.com/orgs/unifiedjs/discussions/193#discussioncomment-3310133.

Solution

@unifiedjs/core Please vote (up/downvote this issue or leave a comment)

Alternatives

n/a

Other than governance (#2), we should draft policies on several things.
In general, I think most policies should be followed by organisations, but I think organizations should be allowed to draft their own policies.

• GitHub organization policy (GH-5) — Define how the GitHub orgs, teams, humans, and repos are managed
• project governance grant policy (GH-7) — define how projects by individuals can move under an organisation
• npm organization policy — Define how the npm orgs, teams, humans, and repos are managed. Maybe one org with teams for respectively the collective and the organization teams? Or orgs for each org team?
• on and offboarding policy — define how individuals become members, and members become emeriti
• .github policy — define how to add contributing, support, issue and pr templates, can be set-up
• moderation policy — define how violations are handled
• fund policy — Define who can request an expense on open collective, for what, and who approves them (I think this policy should be followed by the whole collective)
• consensus seeking policy — define how initiatives are approved or rejects, and which changes require such a process
  ...anything else I’m missing?

I'd like to nominate @Rokt33r for the @remarkjs team.

They've done a cool work with Rokt33r/remark-math, Rokt33r/remark-collapse, Rokt33r/typed-remark, and issues since 2016.

cc: @unifiedjs/core

I'd like to nominate @fazouane-marouane for both the @remarkjs and @micromark teams.

Marouane is doing great work with micromark/micromark#4, helped review GH-2, and and previously worked on remark-jsx. I think Marouane is a great addition.

cc: @unifiedjs/core

Where does onboarding new projects being contributed from the community fit into the governance?

For example @aecepoglu is generously offering to contribute https://github.com/aecepoglu/retext-language-server to the retext organization.

Would that be considered an "initiative" that would be decided by the retext team?

Subject of the feature

Add a new policy that describes where and how funds are allocated.

Problem

It is currently unclear how one could file expenses (e.g., trips), file invoices (like I’m doing), and how the fund is management (why am I currently invoicing the collective).

Expected behaviour

There should be some docs for this. Could be a separate file, or it could go somewhere in the readme maybe (for now?)

Prior art

• https://github.com/nodejs/admin/blob/master/MEMBER_TRAVEL_FUND.md
• 🤷‍♂️

Supersedes GH-6.

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

The current release permission is org based, which could be a security issue, the releasers team should be as small as possible.

Solution

Idea from mdx-js/eslint-mdx#492 (comment)

Alternatives

N/A

Soo, I’m not yet really sure how to set this up properly, so this is a request for comments.

• I think we need teams per org: remark, rehype, retext, mdx, syntax-tree, vfile, unified, etc.
  Different people are into different things; someone could be into retext (natural language) and not care for rehype (HTML)
• We need overarching teams as well: docs, moderation, community
• A core team (steering the whole ecosystem)
• I don’t want to be BDFL

I like Django’s new idea (pointed out to me by @ChristianMurphy), where there’s Mergers and Releasers. Nobody merges their own work, and nobody releases what they merge. I’m not sure whether such a thing works for every org though (e.g., comparing syntax-tree to mdx)?

Further reading:

• https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md
• https://github.com/nodejs/node/blob/master/GOVERNANCE.md

GH launched new team membership roles: triage and maintain. https://github.blog/changelog/2019-05-23-triage-and-maintain-roles-beta/

• Read: Recommended for non-code contributors who want to view or discuss your project
• Triage (beta): Recommended for contributors who need to proactively manage issues and pull requests without write access
• Write: Recommended for contributors who actively push to your project
• Maintain (beta): Recommended for project managers who need to manage the repository without access to sensitive or destructive actions
• Admin: Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository

We’re currently using write or admin rights.

• I don’t think triage is very useful for the collective as there’s more focus on write that on issue handling. We could move the moderation team to that role if it’ll still retain the powers they need
• Maintain is interesting I think because not every releaser needs to be able to do destructive things. Maybe only the team lead will be an “owner” (and the rest of core for the bus factor), whereas other releasers can move to maintain

Note that this feature is rolling out over the coming months, I can’t seem to use it yet.

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

See Motion to nominate a contributor for more information.

See recent work

Solution

@unifiedjs/core Please vote (up/downvote this issue or leave a comment)

Alternatives

n/a

Hi unified collective members! 👋

As described in our governance document, one task of @unifiedjs/core is to review inactive team members, and offboard them. As this is the first time, I’m CCing every non-emeritus member.
After reviewing current members, the following members seem to be inactive and/or have not shown interest in staying on (note that I may have overlooked something):

• @jamesknelson (@mdx-js)
• @komaeda (@vfile)
• @RichardLitt (@retextjs, @unifiedjs/core)
• @sobolevn (@remarkjs)
• @timneutkens (@mdx-js)
• @vhf (@unifiedjs, @rehypejs, @micromark)
• @zcei (@unifiedjs, @mdx-js, @micromark, @unifiedjs/core)
• @zeusdeux (@unifiedjs, @mdx-js, @micromark)

Moving to emeritus status does not mean you or your (past) work is not appreciated. Everyone is still welcome in the unified collective and can still contribute or read along. Emeriti can also be reinstated as active members. This isn’t fun, but there there are advantages of an active group of maintainers (such as security).

Typically we take 72 hours before acting upon something like this, but as this is the first time I’d like to use a full week (168 hours) for members to object.
If objecting, please respond with a description why.
Without an objection, I’ll proceed with the offboarding.

Note that anyone at any time may request to be moved to emeritus status, so if you’d also like to change state, reply below. It’s of course understandable that other things are more pressing than unified.

Note: I don’t think it makes sense that @unifiedjs/moderators needs to be “active” (in the form of comments or issues), so I don’t feel @unifiedjs/core should review whether they are active.

/CC @ChristianMurphy @johno @Murderlon @RichardLitt @zcei @zeusdeux @vhf @BarryThePenguin @Rokt33r @kmck @fazouane-marouane @sobolevn @zeke @ChristopherBiscardi @jamesknelson @Jarred-Sumner @silvenon @timneutkens @komaeda

I'd like to nominate @BarryThePenguin (Jonathan Haines) as a member of the @remarkjs and @syntax-tree merger teams.

He's been helping out and using both organisations for years now!

Hi folks! I wanted to discuss whether it makes sense for us to include GitHub Sponsors references in funding.yml files, next to our OC reference.

Currently with only OC:

OC with GHS (example from Babel):

The reason for discussing this is that I got into the GHS beta (and they’re gearing up to allow anyone to join).

I haven’t mentioned that I got into the beta because I like OC a lot:

• OC is transparent
• OC is about a group of people, not about ego (which really fits with what unified is doing)
• I can quit/be expelled and unified remains

But there are reasons to think about GHS:

• Money is tight, so if people want to sponsor, why not let them 🤷‍♂️
• GH doubles money for now (from the day you join, to exactly a year later)
• GHS is (currently) person to person, which is different from OC, so adding GHS may not mean OC decreases?

What are your thoughts?

Unified has a number of "ideas" repos, this repos predate discussions and were/are designed for discussions which may be long lasting and don't really fit in the issue tracker of a repository.
It seems that GitHub discussions, with it's "idea" discussion type may better serve this purpose.
I purpose adding a comment to each "ideas" repo issue pointing it to discussions, closing the issues, and archiving the repositories.
The mapping from ideas to the respective discussions would be:

• https://github.com/unifiedjs/ideas -> https://github.com/unifiedjs/unified/discussions
• https://github.com/remarkjs/ideas -> https://github.com/remarkjs/remark/discussions
• https://github.com/rehypejs/ideas -> https://github.com/rehypejs/rehype/discussions
• https://github.com/retextjs/ideas -> https://github.com/retextjs/retext/discussions
• https://github.com/redotjs/ideas -> https://github.com/redotjs/redot/discussions
• https://github.com/syntax-tree/ideas -> ??? (not sure with this one, open to suggestions) https://github.com/syntax-tree/unist/discussions

Sid is a member of Gatsby's core team and has a lot of experience with MDX and remark's Gatsby integrations.

npm recently added support for a funding field in package.json: https://github.com/npm/rfcs/blob/latest/accepted/0017-add-funding-support.md#implementation

  "funding": {
    "type": "opencollective",
    "url": "https://opencollective.com/unified"
  },

This’ll standardise that field and I suspect other tools will join in as well.

Laurie is a member of Gatsby's themes team and has a lot of experience with MDX's integration in Gatsby and will be helping us maintain MDX core.

I'd like to nominate @Jarred-Sumner as a member of the @mdx-js merger team.

He's been has been submitting solid PR/issue contributions and is building a product on top of MDX core that is certainly familiarizing him with how the core internals work.