Define roles, qualifications, and privileges

[JordanMartinez]

Preface

Specifically, I'd like this issue to answer the following questions with an official and mutually-agreed-upon answer. First, I will list the questions to answer. Then, I will write down either my current understanding of those questions' answers or what I think should be those answers.

The Questions

1. What are all the roles in the PureScript community?
2. How does each role interact with one another?
3. What qualifies/disqualifies a person for each role?
4. How does one obtain each role?

My Understanding

What are the roles?

• Core Team Member: someone who has write access to the PureScript language (hereafter referred to as the "language repo") and core purescript-* libraries that fall under the purescript GitHub organization (hereafter referred to as the "core PS libraries"). In terms of GitHub roles, this would be a GitHub Organization Owner role.
• Core Library Member: someone who has write access to one or more of the core PS libraries, but not the language repo. In terms of GitHub roles, this would be a GitHub Organization Member role.
• Language Supporter: someone who contributes to the community in a meaningful way that is not directly tied to the maintenance or development of the language repo or the core PS libraries. (For example, infrastructure, documentation, etc.).

How does each role interact with one another?

Each has freedom to contribute in whatever way they choose and as frequently as they choose to contribute.

Core Team Members have final say in decision-making when it comes to the language repo, core PS libraries, and PS infrastructure.

At least two Core Language Members must approve a PR before a merge is allowed in one of the core PS libraries. If another Core Language Member for that repo or a Core Team Member disapproves the PR, consensus must be reached before the PR can be merged. If consensus cannot be reached, the consensus among Core Team Members will have the final say in the matter.

When a non-Core Team Member submits a PR to the language repo, at least two Core Team Members must approve a PR before a merge is allowed. If at least one Core Team Member disapproves the PR, consensus must be reached before the PR can be merged.
When a Core Team member submits a PR to the language repo, at least one other Core Team member must approve the PR before a merge is allowed. If at least one Core Team Member disapproves the PR, consensus must be reached before the PR can be merged.

If a situation arises that requires consensus among Core Team members and such consensus cannot be reached, the decision will be postponed.

Language Supporters who have express control over their project/work can ignore feedback from Core Team Members and/or Core Library Members. However, Core Team Members can drop any "official" stamp they previously gave to the project/work of said Language Supporter at any time.

What qualifies/disqualifies a person for each role?

A person will be disqualified from a role if said person exhibits assholery in that they continually show disrespect to and disdain for others, regardless of who that person is and what role they may or may not serve in the PS community.

Qualifications for each role:

• Core Team Member
  • has been an "active member" in the community for the past year
  • has made at least 5 "non-trivial" contributions to or made releases for the language repo and/or core PS libraries in the past year in any combination (e.g. 1 release + 4 contributions; 5 releases + 0 contributions; etc.)
• Core Library Member
  • has been an "active member" in the community for the past 6 months
  • has made at least 10 contributions to the same repo or has created a project that Core Team Members and said core developer have agreed to relocate under the purescript GitHub organization.
• Language Supporter
  • has been an "active member" in the community for the past 6 months
  • desires to contribute to the community in some specialized way that does not directly relate to the language repo or core PS libraries.

Note: by "active member," we mean "has chatted with others in the FP Slack; opened and/or responded to threads in the PureScript Discourse forum; contributed PRs and/or opened issues in a PureScript project; and/or created blog posts, videos, talks, etc. for PureScript"

How does one obtain each role?

Language Supporter

To determine whether they've been around for at least 6 months, the person must open a thread in the Discourse forum, referring back to the first time they first started being active in the PureScript community and indicating one of two things:

1. what they would like to help with and the experience/knowledge they have that qualifies them to do that role
   1. For example, a person asks whether and how they can help out with Infrastructure-related things.
2. what projects they would like an "official" stamp on
   1. For example, someone creates a well-developed tutorial and would like their work to be linked to on some official PS site (e.g. documentation repo)

In the first situation, either a Core Team Member or Core Library Member will respond to them within 1 month and indicate whether such a need is needed, whether the person is currently competent enough to do that without much/any hand-holding (note: this is not meant as an insult; just an honest "there's not a lot of time to spend on supporting such people right now unfortunately. So, if they can't do it, then we shouldn't agree to grant such a role to them either"), what they could potentially do to become more competent if that's needed (just because they can't now, doesn't mean they can't in the future), and what support they could provide the person. The two parties will decide upon an action plan from there.

Core Library member

When the person wishes to obtain access to a core PS library repo, the person must contribute to the repo in question at least 10 times, and then open an issue in that repo expressing their desire to obtain this role. Other Core Library Members will discuss with that person whether they should be granted that role or not.

When the person wishes to relocate a project/work that they have created into the GitHub purescript organization, they person must first create such a project/work, receive wide-spread community support as evidenced by at least 200 stars on GitHub, and then open an issue in the purescript/governance repo concerning the relocation of the repo. If Core Team Members approve, the relocation will occur and the core developer(s) of that project will be granted the GitHub Member role for that repo.

Core Team Member

To obtain this role, a person must do a number of things:

1. Read through the following books/papers, so that they will have a better understanding of the nuances of language development:
   • Type Theory and Formal Proof: An Introduction
2. Write or update documentation for others in explaining how specific parts of the language works (note: the goal here is to make it easier for future contributors or one-time contributors to contribute and also weed out those who aren't serious about the long-term commitment)
3. Make at least 5 non-trivial (e.g. documentation, one-liners, etc. don't count) contributions to the language repo

Thoughts? I couldn't come up with a better name for the first version of 'Language Supporter' that is looking to help with maintenance and isn't looking for an "official" stamp sort of thing.

[garyb]

Some quick initial thoughts:

I think 200 stars for a library is perhaps a bit of a high bar? There are only 18 projects on GH that meet that threshold currently, and not all of them are libraries even. I don't really use stars myself, if I star something it's because I intend to check it out at a later time perhaps, but realistically I look at that list maybe once a year. 😉 I guess the intent is to have it as a popularity metric, and I don't really have any better idea for one if we want to do that based on a concrete number.

I'd also say popularity doesn't necessarily make a library "core-ish" - Halogen is the most-starred PS library, but it certainly doesn't belong in the PS org. I'd say "core-ness" is more based on a library providing fundamental building blocks for a program. There are perhaps some existing core libraries that don't entirely fit that, like quickcheck and minibench, but minibench at least is a dev dependency of some of the other core libraries if I remember rightly, and maybe QC is too.

Another aspect of "core-ness" is perhaps also that they're basically done - there's maybe room for some minor additions, but without changes to the language there should be very few reasons to make breaking changes in them.

That's all assuming we're basically sticking to things the way they are now though. 🙂

Core team member: I certainly haven't read that, or the oft cited TaPL 😄. I've read some papers and things, mostly for reference material, but I don't think it needs to be a requirement - there's plenty of things that can be worked on in the compiler that don't require touching the type checker. I think just making a number of non-trivial contributions and demonstrating an understanding of the ethos and goals of the project (which are some more things that should be codified really) would be sufficient.

[dariooddenino]

Maybe having read that book shouldn't be a requirement, but I REALLY like this part:

Write or update documentation for others in explaining how specific parts of the language works (note: the goal here is to make it easier for future contributors or one-time contributors to contribute and also weed out those who aren't serious about the long-term commitment)

I've done some minor / trivial contributions, and I found that most of the time I spent was "wasted" on figuring out the project structure, what was doing what, how to properly debug and setup things, etc.

Maybe this topic should have it's own issue :D

[JordanMartinez]

Perhaps that's another question to be clarified first: what criteria must a library meet to be considered a "core PS library"? Based on what you said the criteria might include the following:

• acts as a fundamental building blocks for most PS programs (e.g. most real-world projects will either use these libraries directly / indirectly through a long chain of transitive dependencies)
• generally complete (only time it needs to be changed is when language introduces breaking changes)

Perhaps this should be discussed in its own issue?

[JordanMartinez]

I don't think it needs to be a requirement - there's plenty of things that can be worked on in the compiler that don't require touching the type checker. I think just making a number of non-trivial contributions and demonstrating an understanding of the ethos and goals of the project (which are some more things that should be codified really

Makes sense. I think the question I was trying to answer was, "What would have to occur for Core Team Members to trust someone else to make changes to the language without huge concern?" Being competent is one such factor, but I hadn't considered the possibility of specialization within the Core Team Members.

What is the ethos of the project? It seems to be

• progress slowly, so that changes are well-thought-out and don't lead to unintended consequences
• if it can be done using the language as a library, implement it there rather than inside the compiler
• prefer not to introduce new syntax, so that the language remains small / breaking changes occur less often
• consider how such changes will affect the ecosystem (maybe this won't be as big of a concern if updating the ecosystem can be done faster in the future...?)
• do it right the first time, even if it's harder

Write or update documentation for others in explaining how specific parts of the language works
I've done some minor / trivial contributions, and I found that most of the time I spent was "wasted" on figuring out the project structure, what was doing what, how to properly debug and setup things, etc.

Getting that documented would likely help new contributors actually contribute. I was looking at the source code recently and it took a while to figure out where to start, what does what, and a large overview of the flow of code.

[natefaubion]

I think it needs to be clear that the goal of the org is not to amass projects (and thus responsibilities). We want to amass contributors so that any given contributor has less individual responsibility. What we have in the org are things that are pretty fundamental to using the language and the ecosystem, and the requirement that core only depends on core naturally lends to other offshoots so we can do basic things like testing or performance measurements.

I'm wondering if it would be a simplification to have a periodic nomination process, where users can anonymously nominate libraries and contributors to teams, which are voted on by existing members of the org as a whole, and those accepted can either choose to join or not join. This would give us an opportunity to stop and reflect on those making an impact in the ecosystem, rather than the current ad-hoc "hey what about that person" decisions.

[natefaubion]

To follow up, I think a big problem with the status quo is there is no reflection, or if it is, it is ad hoc. There isn't a deliberate, recurring process by which we (as a whole community) stop to reflect and thank those contributors making an impact. The problem I have with the above outline is that it kind of pointifies/gamifies it. To me it reads like, "level up today!" as a way to drive engagement. I recognize that's a bit cynical. But most contributors are doing what they do because they love it, and we like to continue doing it because others love the result of our work and the impact it makes on the learning process, work life, etc. I'm just wondering if there's an opportunity for us to collectively stop, recognize, and thank those contributing in what little way we can. Titles can be obtuse, sure, but it's also a way we can recognize what someone has done and show that we trust them. The current process of "you make your own way, and only get something when you ask for it and make a case" is frankly disheartening.

[Woody88]

I'm just wondering if there's an opportunity for us to collectively stop, recognize, and thank those contributing in what little way we can. Titles can be obtuse, sure, but it's also a way we can recognize what someone has done and show that we trust them. The current process of "you make your own way, and only get something when you ask for it and make a case" is frankly disheartening.

I strongly agree with this. I wonder if there is a sort of recognization system that can be put in place for contributors, popular and unfamiliar libraries. It can be done bi-monthly or whatever period that works for the community. We can also have something showing recognization on Pursuit, sort of how cargo does it and display the bi-monthly people/library that we want to thank on Discourse - like this we can have more people also use discourse and pursuit to see how people are helping the community, two birds one stone...

P.S: This can also allow new contributors to see how people are engaging in the community so they can do the same.

[JordanMartinez]

The problem I have with the above outline is that it kind of pointifies/gamifies it. To me it reads like, "level up today!" as a way to drive engagement. I recognize that's a bit cynical. But most contributors are doing what they do because they love it, and we like to continue doing it because others love the result of our work and the impact it makes on the learning process, work life, etc.

Even if it is read in a somewhat cynical way, there's still truth in that perspective. It sounds like you are suggesting the above outline be reworded, so that it tries to encourage people to contribute because they love doing such work rather than treating everyone like we're in some MMORPG where everyone is competing with one another in terms of leveling up their character, armor, weapon, skills, etc.

For example, instead of a perception of "you must do X, Y, and Z before you can contribute; once we see that you are worthy, we'll welcome you," it is perceived instead as "if you want to work with us to make great software, we welcome you."