Alternative flow for managing participation about participate.whatwg.org HOT 15 CLOSED

So if GitHub was willing to add features for us, this could be solved with either:

• The ability to create public teams for an org, which are readable through the GitHub API with no privileges
• Some kind of "sub-organization" that might help organizations reduce the confusion about having multiple organizations.

The first seems nicer, and would also solve #12.

from participate.whatwg.org.

Looking at https://developer.github.com/v3/repos/collaborators/ this seems like an experimental API. On top of that it's not entirely clear to me if we could access such data. I think currently all that information is privileged.

from participate.whatwg.org.

Right, when I last looked into this, most of this sort of data is very private and can't be accessed by @whatbot. (E.g. team membership, even for public teams.)

Organizations was the only public thing I could figure out. But if you see something else in the GitHub API that is publicly accessible, let me know. You can test by just accessing it in your browser: see e.g. https://api.github.com/users/domenic/orgs.

from participate.whatwg.org.

I'm not 100% on the context here, but would nested teams help? Inside the whatwg org, you could have a participants team which itself has a set of sub-teams named after the companies, each company team can have a team admin who can add their colleagues. Would this solve the issue?

from participate.whatwg.org.

@keithamus I think for Mozilla it would not as we plan to eventually have automated control over who gets to join and who has to leave the organization that controls our standards participation. Having to manually manage that for lots of people will lead to mistakes. And I don't think WHATWG is comfortable allowing bots from all the organization that join us to poke around and make those changes.

from participate.whatwg.org.

Is it possible to use the nested teams idea as an alternative optional flow? For me, I only have a handful of people that will be contributing, so managing it manually won't be a problem. (and creating a full fledged organization seems like an overkill)

from participate.whatwg.org.

Nested teams seems like a potential workaround, but it feels wrong to have this be "under the WHATWG" instead of "under the company". Companies would also need to be careful to keep @whatbot on their teams and never accidentally kick it off, further making it feel less like their space and more like ours. In general, they'd need to invest a lot of trust in WHATWG admins not to manipulate the contents of their teams; we'd have no incentive to do so, but it still feels like a weird dynamic.

@yoavweiss, we could build a whole alternate flow around nested teams, but we'd need some convincing that it's worth the engineering time. So far all you've said is that "a full fledged organization seems like an overkill", but I don't really understand that. Organizations are free, easy to create, easy to administer, and several companies are already using them in this manner. They seem much less like overkill than teams, which in GitHub's data model are rather complex entities.

I guess #12 is an argument for spending engineering effort on the nested-teams workflow.

from participate.whatwg.org.

Right now my legal team's opinion is that we'll need to create a separate paid organization for this purpose (As according to GH ToS: "the ToS specify that an entity can have only one free account per entity").

The cost is not huge but not negligible either (9-21$ per member per month, I'm not yet sure which plan we actually need for that). This adds friction to the signing process as I figure out if the existing org account can upgrade itself, or I need to create a new one.

At the same time, are nested teams at the organizations more visible than simple teams? I thought the reason we didn't go with org teams is that the information is behind a login.

I also poked at the GH APIs and I think there's a simpler alternative to nested teams: Repo collaborators.

It seems easy to extract contributors from a specific public repo.
e.g. curl -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/WICG/starter-kit/contributors will give you a list of everyone who contributed to this specific public repo.

So an organization can specify a specific repo that every contributor to that repo will also get permissions to contribute to the WHATWG. It'll be a bit tricky to manage memberships (e.g. removing a contributor will require history rewriting), but it seems like a simple alternative to get started.

from participate.whatwg.org.

The teams proposed above would be under the WHATWG organization and have whatbot as an administrator, so they would be visible to whatbot through the API.

We could indeed hack up something based on any world-readable piece of data, such as collaborators on a repo, a Twitter list administered by an employee, or a file at a .well-known location on the entity's website. All of these require nontrivial engineering effort to build into the workflow, and will need to be supported indefinitely. So I'm not eager to pick any in particular unless we are sure it is long-term the best option. So far everything proposed seems pretty terrible, but I agree that between the $9 cost and the requirement to publicize membership one by one (#12), I can see why organizations are suboptimal.

Still, I would advise anyone wanting to be able to sign and contribute in the near future to go that route for now. Any alternative we come up with is not going to be fast to decide on or code up, test, stage, and deploy. (I'd estimate on the order of 3 weeks-2 months.)

from participate.whatwg.org.

Currently I'm leaning toward allowing companies to enter a URL that contains a text file with a list of GitHub usernames they want to allow to contribute. The contents of that URL could be administered any way they want; e.g. it could be the githubusercontent.com version of a .txt file in some repo they control.

How does that sound to folks? I'm not sure how fast I could make it work, but I do want to walk back a bit from my previous longer estimates of 3 weeks-2 months, as upon further reflection on the situation it seems like the potential TOS violation/cost of rectifying that is pretty serious, and so this should be treated as more urgent.

I'm still leery about supporting too many alternate workflows, e.g. organization (optimal for Google), this URL thing (optimal for a number of others perhaps), and perhaps in the future something based on GitHub teams if they become public. So let's make sure this new proposal makes people happy.

from participate.whatwg.org.

I'm happy with a txt file based alternative flow.

from participate.whatwg.org.

As an update, I was able to start coding on this today, and have made significant progress. I hope to have something to show this week.

(Edit: this did not happen, as the day after I said that, I got sick and knocked out of commission for a week -_-.)

from participate.whatwg.org.

Update on my end: managed to (finally) sign the participant agreement by creating a new Github org, using the team plan, paying the minimum 25$/month.

I'd still highly appreciate if we could get rid of this requirement as it creates a monetary barrier to participation, as well as a legal and bureaucratic one.

@domenic - hope you're feeling better. Anything I can help with to make that happen?

from participate.whatwg.org.

So sorry about that; it's still a high priority to fix. I am feeling better, but now have less time due to various events I'm traveling to.

If people are interested, I could upload my half-baked code for this and others could try to contribute to that branch. Otherwise, I'll get back to it as soon as I'm able.

from participate.whatwg.org.

Is this still something that people need?

from participate.whatwg.org.