How to join the OpenCilk community

[behoppe]

We'd like a way for people to sign up as members of the OpenCilk community. For example, a visitor might see "Site under construction" with a "sign up" link to get notified when we officially "release" the site. Also, a professor might sign up so that they can access editable teaching materials.

Short version: I recommend adding a contact form for now, and then later considering something like Mailchimp as well.

Longer version:

I originally envisioned Mailchimp (or HubSpot, etc.) as our tool for managing these sign-ups, but as I learn more about GitHub teams (with their discussions and access permissions), I am less sure about the need for Mailchimp. It seems that GitHub teams and discussions can provide the "real" (operational) user management and communication that we need. So why use another platform to store segmented user information, if that platform (Mailchimp) is redundant to our processes?

Unfortunately, GitHub does not provide a way for a person to request membership. ("I want to hear about the next release." Or, "I want to get access to editable classroom materials.") When we use our GitHub organization and affiliated teams, the only way people can join is after we invite them. There may be third-party workarounds, but probably not for small use cases like ours.

In order for people to request membership (or initiate contact in general), we might use a contact form (such as described here). The form might send emails to me, or to a mailman email list of our choosing.

At this point, I think newsletters are the deciding factor for a tool like Mailchimp. We can use GitHub discussions for announcements, but if we want something "glossier," then we'll probably want Mailchimp. (I see that sites like Numpy.org and Julialang.org have Mailchimp sign-up forms in their footers, FYI.)

[behoppe]

Yesterday I discussed "OpenCilk contact information" with @cleiserson and we agreed I should bring a quick summary recommendation to @dcurtisatmit and @neboat.

Recommendations:

• We continue using contact@opencilk.org (as promoted on the old site). This address would be the default destination for the www.opencilk.org contact form and the default address we would publish anywhere that people want our contact info.
• We continue to monitor opencilkcorebugs as the destination for contact@opencilk.org (or optionally we can update email forwarding and review these emails somewhere else).
• Bruce or Dorothy would ensure that someone responds promptly to any inquiry -- by emailing them directly and/or inviting them into our GitHub OpenCilk organization (or another appropriate channel, so as to reinforce the ecosystem documented by our own Community page).

This policy would affirm that the GitHub OpenCilk organization acts as our ecosystem membership list. With our GitHub Free plan, we can add as many members as we want to our organization at no charge. If we decide later to upgrade to fancy GitHub code management features, we would switch to a paid GitHub plan, at which point we'd start paying on a per-user basis. If we have hundreds of members, that upgrade would sting, but I think we'll switch discussion forums before that scale happens. Because when we get a truly active discussion forum, then I recommend we consider Discourse instead of GitHub discussions (as described in Integration/Q&A near the end of the website proposal).

[behoppe]

With Netlify Forms, I added a contact form with a9b105588ee830f5e22226a2652ad3c504792edb and 1a8f6f0a73ce41c9ac2d600b7543b286d33a2ef1, but there were a couple problems.

• The big problem was that name and address were not getting sent by the form, only the message.
• Also the form was going into Netlify data, not emailing us.

I need more time to review this form support guide and see why some fields are being ignored when the form submits.

In the meantime, I removed the form and replaced it with a simple "email us" per 8fc2fdf4b29b8e8251f699a9fb1716352c915db9.

[behoppe]

The contact form works:

• user provides name, email, and message
• form is managed by Netlify
• Netlify sends notification email to contact@opencilk.org, which includes the input fields of the form.

Later we might want to customize the form per https://docs.netlify.com/forms/notifications/ (e.g., subject for a reply email).

I am leaving this issue open because "how to join" is still not resolved. In particular, I have concerns about using our GitHub organization discussion as the home base for membership. (For example, see #42.)

[behoppe]

@DorothyCurtis thank you for suggesting that we implement a sign-up form in time for SC22. This issue is home base for work related to that. In summary, here are some dimensions of "How to join" (a topic officially presented in https://www.opencilk.org/community/)

• How to get your name and email on "our list". Right now this is served by the contact form. There are lots of easy ways to deploy other forms to collect names and emails (e.g., Google forms).
• How to become a member of our public discussion forum. Right now our public discussion forum is GitHub discussions for the OpenCilk organization. There are shortcomings to this approach that are documented in the comments above. Because we have so little traffic (essentially zero public discussion to date) I recommend a patient approach to deciding on changes to this forum.
• How to subscribe to our newsletter. We have discussed publishing a newsletter in the future, but we don't have one now, which is partly why I think we might want to simplify "How to join" to "How to give your name and email to the OpenCilk team."

[behoppe]

Thank you @neboat and @DorothyCurtis for alerting me to your concerns about access to the private repositories owned by the OpenCilk organization. Here I propose how to remedy that issue, and I review "how to join OpenCilk."

Very briefly:

• I recommend we change the base permission of OpenCilk from "Read" to "No permission." Then we remove access to private repos that was accidentally granted to two people last week. Moving forward, we use GitHub teams to explicitly grant access as needed. (For example, we might create a team "Private read" if we wanted to duplicate the effect of the old base permission.)
• I recommend we maintain our current "how to join OpenCilk" policy. We use OpenCilk membership as the official ecosystem membership list, and we use the GitHub OpenCilk discussion forum as the official public forum.

More below:

Changing base permission looks like this:

Revoking individual user access will be simple after base permission is adjusted:

More on how to join OpenCilk:

• We promote contact@opencilk.org as the organizational email and monitor opencilkcorebugs as the destination for emails sent to contact@opencilk.org.
• Bruce or Dorothy ensure that someone responds promptly to any inquiry -- by emailing them directly and/or inviting them into our GitHub OpenCilk organization (or another appropriate channel, so as to reinforce the ecosystem documented by our own Community page).
• Bruce also monitors responses to the Join us page (which are processed by a HubSpot form that notifies Bruce's MIT email) and processes them similarly.

Thoughts about GitHub organization membership from my July 14 comment on this issue:

This policy would affirm that the GitHub OpenCilk organization acts as our ecosystem membership list. With our GitHub Free plan, we can add as many members as we want to our organization at no charge. If we decide later to upgrade to fancy GitHub code management features, we would switch to a paid GitHub plan, at which point we'd start paying on a per-user basis. If we have hundreds of members, that upgrade would sting, but I think we'll switch discussion forums before that scale happens. Because when we get a truly active discussion forum, then I recommend we consider Discourse instead of GitHub discussions (as described in Integration/Q&A near the end of the website proposal).

[neboat]

@behoppe, I think your proposal sounds reasonable.

I am wondering, though, what exactly are we using membership with the OpenCilk GitHub organization for? Membership with a GitHub organization primarily serves as a mechanism to easily grant users access multiple repositories in that organization. (Access to individual repositories can be done by adding that user as an "outside collaborator" on that repository.) If OpenCilk members don't have any additional access to repositories compared to nonmembers, then what's the benefit of simply making someone a member? Are we using membership with the OpenCilk GitHub organization for some other purpose?

[behoppe]

Thanks @neboat. I'm glad this sounds reasonable. I would say the main reason we're granting membership to the OpenCilk GitHub organization (as proposed) is to allow them to read (and hopefully write to) the organization-level GitHub discussion forum, which is our official place for public discussion. (There is a separate issue #42 that discusses some of the ins and outs of the organization-level discussion forum.)

[neboat]

@behoppe, are you talking about this discussion forum? https://github.com/orgs/OpenCilk/discussions.

Nonmembers can already read and write to that discussion forum, as long as they're already logged in to GitHub. We already have an example of a nonmember (jasonreidy) using that discussion forum to ask us a question about OpenCilk. I don't see how membership in the OpenCilk organization changes how people can use that forum.

[behoppe]

Thank you @neboat, I see that I can read the discussion forum even when I'm not logged in. I'm not sure what to make of this, since I explicitly tested this property and documented my findings several months ago. Clearly what I thought is now not the case, and I no longer have a ready answer to how we use organization membership. That said, we do need a place where we maintain our official list of ecosystem contributors. I think HubSpot CRM will hold the part of that list related to potential educational contributors, and I think we may still want to use organization membership here for the rest of that list (e.g., everyone who provides us with their contact info so that we can discuss OpenCilk with them). But using organizational membership in such a broad manner is, I admit, probably not what most expect from "organizational membership."

So, long story short, I am open to amending my proposal by storing our ecosystem membership records somewhere other than "organization membership." I would still change base permission from "Read" to "No permission." And I think we're agreed that GitHub teams will probably be how we define content access across the ecosystem.

PS: I am at least a little reassured to see that GitHub documentation is still framed entirely in terms of what "organization members" can do with discussion forums, which let's me believe that at one point non-members were not allowed to do anything with discussions.

PPS: Thanks for mentioning jasonreidy. I missed that, and I will pay closer attention for the "Discussion" label in my notification stream. Thanks for helping him!

[behoppe]

Hi @neboat and @DorothyCurtis, I am going to try to integrate some of our recent "join"-related emails into this thread. My top-level hope in this post is that we agree to some multi-level notion of membership in OpenCilk that enables me to start using membership for the well-qualified teachers who want to participate in our ecosystem. More below.

From Dec 15:

Honestly, this gives me some clarity on how messy the current organization membership is and how messy repo access seems to become once we change the default level of access.

Two comments on this important concern:

• I agree that current organization membership is messy, in the sense that we seem to lack a notion of what it means to be a member. I suggest we define "membership" (in the OpenCilk organization) so that it isn't reserved for a handful of insiders, but accommodates a range of membership levels that make OpenCilk membership relevant to many of our potential ecosystem contributors. I think GitHub provides ample configuration options to let us create these levels. By taking advantage of that, we can make OpenCilk membership a "tangible" process for people who show specific interest in participating in our ecosystem long before they qualify as "insiders" like our current members appear to be.
• Given how small our organization is right now (18 members with a handful of private repos), I think it would be fairly simple to change default level of access to "No permission," and then manually set each person's access to each of our private repos. I recently created and shared a "private repo access matrix" to make it easy to specify who needs access to what, which I would be happy to implement, if we want.

A bit after Dec 15, we discussed that organization members can create repositories, which we don't want them (in general) to be able to do. But GitHub "Member privileges" allows us to edit this as we wish. Below is a brief overview of the editable privileges that I recommend changing:

• Repository creation:
  • Current: members can create public and private repos.
  • Recommended: members cannot create repos (without specific individual authority)
• Repository forking
  • Current: members can fork private and public repos
  • Recommended: members can only fork public repos
• Pages creation
  • Current: members can create public sites, visible to anyone
  • Recommended: members cannot create sites
• Team creation rules
  • Current: members can create new teams
  • Recommended: only organization owners can create new teams

(I have omitted a few editable privileges that I think we can leave as-is.)

Finally, I would like to let teachers into our new private repository, "teaching resources." Based on my top-level argument that we define "membership" broadly with multiple levels, not narrowly, I would like to add teachers to the OpenCilk organization and make them members of the new @OpenCilk/teachers team, which would govern access to the "teaching resources" repo. Below are the options for how we can assign team privileges for a repository. I recommend we use "Read" access for the teachers team, which would allow us to reserve greater access for nested sub-teams or individuals. The other options are below, fyi.