whatwg / participate.whatwg.org Goto Github PK

This is done in a few places, but @terinjokes noticed that you can get a server error (instead of a nice up-front client error) if you only fill out some of the backup contact info.

Server logs say

[participate] [2023-07-26 12:47:03] Error: Request failed with code 401
[participate] [2023-07-26 12:47:03]     at RequestHandlerHelper.createResponseError (/app/node_modules/twitter-api-v2/dist/cjs/client-mixins/request-handler.helper.js:103:16)
[participate] [2023-07-26 12:47:03]     at RequestHandlerHelper.onResponseEndHandler (/app/node_modules/twitter-api-v2/dist/cjs/client-mixins/request-handler.helper.js:252:25)
[participate] [2023-07-26 12:47:03]     at IncomingMessage.emit (node:events:525:35)
[participate] [2023-07-26 12:47:03]     at endReadableNT (node:internal/streams/readable:1359:12)
[participate] [2023-07-26 12:47:03]     at process.processTicksAndRejections (node:internal/process/task_queues:82:21) ApiResponseError: Request failed with code 401
[participate] [2023-07-26 12:47:03]     at RequestHandlerHelper.createResponseError (/app/node_modules/twitter-api-v2/dist/cjs/client-mixins/request-handler.helper.js:103:16)
[participate] [2023-07-26 12:47:03]     at RequestHandlerHelper.onResponseEndHandler (/app/node_modules/twitter-api-v2/dist/cjs/client-mixins/request-handler.helper.js:252:25)
[participate] [2023-07-26 12:47:03]     at IncomingMessage.emit (node:events:525:35)
[participate] [2023-07-26 12:47:03]     at endReadableNT (node:internal/streams/readable:1359:12)
[participate] [2023-07-26 12:47:03]     at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
[participate] [2023-07-26 12:47:03]   error: true,
[participate] [2023-07-26 12:47:03]   type: 'response',
[participate] [2023-07-26 12:47:03]   code: 401,
[participate] [2023-07-26 12:47:03]   headers: {
[participate] [2023-07-26 12:47:03]     perf: '7626143928',
[participate] [2023-07-26 12:47:03]     'content-type': 'application/problem+json',
[participate] [2023-07-26 12:47:03]     'cache-control': 'no-cache, no-store, max-age=0',
[participate] [2023-07-26 12:47:03]     'content-length': '99',
[participate] [2023-07-26 12:47:03]     'x-transaction-id': 'e1d25a511ed69c7f',
[participate] [2023-07-26 12:47:03]     'x-response-time': '4',
[participate] [2023-07-26 12:47:03]     'x-connection-hash': '66e8051a666d6f29f78733a42b341f6291adda1f0e97054487638530d6b1f583',
[participate] [2023-07-26 12:47:03]     date: 'Wed, 26 Jul 2023 12:47:03 GMT',
[participate] [2023-07-26 12:47:03]     server: 'tsa_b',
[participate] [2023-07-26 12:47:03]     connection: 'close'
[participate] [2023-07-26 12:47:03]   },
[participate] [2023-07-26 12:47:03]   rateLimit: undefined,
[participate] [2023-07-26 12:47:03]   data: {
[participate] [2023-07-26 12:47:03]     title: 'Unauthorized',
[participate] [2023-07-26 12:47:03]     type: 'about:blank',
[participate] [2023-07-26 12:47:03]     status: 401,
[participate] [2023-07-26 12:47:03]     detail: 'Unauthorized'
[participate] [2023-07-26 12:47:03]   }
[participate] [2023-07-26 12:47:03] }

Not so optimistic this time about fixing it; we'll see.

https://docs.github.com/en/rest/reference/checks

This seems like it might be more suitable for PR-focused checks. Our current use of "commit statuses" leads to issues like #172.

I am aware of some other CLA-checker services making this switch currently.

It's not quite 100% and that might be good.

That is, currently GitHub doesn't allow an organization to force its members to demonstrate membership. It's a choice of the members.

This might not be clear to the person signing the agreement and it might not be clear to the members of the organization either. We should probably have some guidance, including specific instructions, to help with this.

We now have our first invited individual:
https://github.com/whatwg/participant-data/blob/6ed532d651106578ffa550eff2ab01d117783481/individuals.json#L3076-L3088

Per whatwg/sg#157 (comment) this invitation is valid for 36 months, so before those 36 months have passed we need to add a mechanism for an end date, at which point the participation check should start failing and say that the agreement needs to be revisited.

Unlike most WHATWG sites which are static, public resources, this site could actually benefit.

https://csp.withgoogle.com/docs/strict-csp.html

Currently we require it because we expect updates to the CWA to be done via pull request; see https://participate.whatwg.org/agreement-update. However, we could always accept update requests from the (provided) email.

Longer-term, we probably will have a nice web interface for updates, but even that will rely on GitHub authentication. (Unless we want to create our own username/password database, which seems unwise.)

I'm not sure if we should change this, but it's worth considering...

Apparently it was not being maintained, and then got sold (!) to an unknown third party. We've locked our version so we shouldn't be susceptible to any new malicious code published, but being on an unmaintained thing is bad anyway.

I've asked for replacement suggestions at https://mobile.twitter.com/domenic/status/1096552441900920834

While working on #158 I noticed that the code here seems to assume that a repository is 1:1 with a Workstream. That's also why we added the id field to db.json it seems. But this is not the case. Standards are 1:1 with repositories and the shortname of the standard (which you can extract from the URL) is equal with the repository name. This is what our other scripts do.

I was looking for the equivalent of https://github.com/whatwg/meta/blob/main/review.py#L32-L44.

https://twitter.com/htmlstandard/status/1425927738905538564

I sometimes get "502 Bad Gateway", implying that nginx can't find the backing node server, after a Travis CI initiated deploy. Re-deploying, or SSHing in to restart, fixes it.

I'm not sure how to debug this or what could be going wrong here, but I want to file a tracking issue at least. Maybe I'm not using pm2 correctly :-/.

A typo in https://github.com/whatwg/participate.whatwg.org/blob/master/lib/app.js will not be caught by the current test suite, but will cause the server to fail to start (resulting in 502 bad gateway in production). It'd be good if CI ran a few tests of app.js.

whatwg/participant-data@815fbc6 added a user under the name "johanna-hub", but the official spelling of their username is "Johanna-hub", with an uppercase letter. So the PR whatwg/html#4068 was initially marked as not-OK.

I manually fixed participant-data as a one-off in this case. But, we should consider a better solution for the future. Either case-insensitive comparison, or canonicalization, or...

Related: #8.

https://dependabot.com/ sends PRs for node dependencies, and I've found it to be quite nice for some other personal projects.

@domenic have you used this, and WDYT?

whatwg/xhr#303 is a spam PR where someone forked whatwg/xhr, and then PRed from the annevk/response-fragments branch on their fork to the master/main branch on whatwg/xhr.

This overwrote the IPR status on the actual PR, whatwg/xhr#200.

This kind of makes sense in that IPR status is reported on a commit, so if it's the same commit hash, I can see how a conflict would arise.

This is similar to #33 but not quite the same.

Unfortunately the "Recent Deliveries" tab for the webhook does not have that spam PR (it's been too long). So I can't inspect the body to figure out a good way of detecting this. If something similar happens, post here and we can capture it. Or, we could reproduce the situation ourselves I suppose.

This is the sister issue to whatwg/meta#251

to make it slightly more tolerant to the case
https://github.com/whatwg/participate.whatwg.org/blob/main/lib/compose-tweet.js#L5

At the moment, you can eventually find something in the way of an answer by going from WHATWG home -> Participate -> Working Mode (read a lot till you find the relevant heading), but that really just says that it will be incubated outside of any WHATWG standard, so… where do I send a proposal? Who to? Where?

See the thread from https://twitter.com/troglotit/status/1109568782215852033.

Currently in order to manage participation, a company has to create a dedicated Github organization and make sure all its members are people that are allowed to contribute to WHATWG standards.

While that's feasible and free-of-charge, it can create confusion for companies that already have an active Github organization that's not related to standard participation.

It'd be great of an alternative flow was enabled, that doesn't require a full-fledged separate GH org. One alternative can be a separate repository on an existing org, where all the repo admins are tracked as people that can contribute to WHATWG standards.

The plan is to have a page (on participate.whatwg.org) where you can sign up to get automatically added to a @whatwg/review-draft-watchers team, by clicking a single button.

Then, we ensure that review draft publication always pings this team. (Exact details TBD, but could be as simple as the editor remembering to ping that team when they announce the review draft. Ideally that announcement is helped by tools, in which case we make sure the tool generates the appropriate ping in its output.)

This code, and its counterpart below for entities, is bad:

In particular, if a modification occurs to the file contents between them being fetched and them being updated (between lines 6/7 and lines 32/35), those modifications will be overwritten. (There is no "lock" on the "database".)

Fortunately this is not the end of the world as if someone signs the form, but then it gets overridden, this problem will be easily seen in Git history, and can be corrected by humans. And unlike many production databases, we don't expect this to have high QPS, so it's unlikely to happen anyway.

Still, this code is bad and I feel bad for writing it.

The correct fix here is to use Git's conflict resolution mechanism. That is, instead of using the update-file-contents part of the GitHub API, use the submit-and-merge-a-pull-request part of the GitHub API. This would still be done with no human intervention, but it would go through the merge process, thus guaranteeing either a merge conflict or a successful merge.

This has the added benefit that you can watch the participant-data repository to see new entities and individuals get added.

It prevents pasting in URLs that contain a fragment identifier, which is somewhat typical for a PR to contain. We could probably just make the regular expression more complicated.

This is a follow-up on whatwg/misc-server#53.

After autodeploy we should use pm2 to restart.

Ideally we should autodeploy private-config.json from a private repository as well? That can be done later though.

@foolip, I was thinking of just setting up a Travis file that does rsync on the file contents and then uses SSH to execute the restart command. The SSH key would be encrypted in the same way we do for specs. Any thoughts or concerns?

I guess we want the standard WHATWG CC license here due to it including SG text.

The current link for the "good first issue" tag throws a 404 error when the user is not logged in with a GitHub account.

I propose that this link be used instead since observers can view the page without having to log in (and aren't greeted with a 404 error implying that the link is broken).

Advantages:

• Doesn't 404 when the user isn't logged in with a GitHub account
• Larger font size given to the number of open issues
• Excerpts for each issue make it easier to understand the topic at hand
• IMO easier to see which repository each issue is in (the current link hides repository names in the issue title)

Disadvantages:

• Less issues per page (this probably doesn't matter since newcomers will want to choose one issue and work on that)
• Tags aren't visible (could be considered both an advantage and disadvantage)

Wouldn't mind making a pull request to fix this.

Filling out the form always seems to give me a 500 error:

I've tried a few different times but this error seems to persist. Are you able to reproduce this error?

E.g. in whatwg/html#3512 if you expand "View Details" then click "Details" next to the Participation line, you're taken to https://participate.whatwg.org/agreement-status?user=annevk&repo=html.

Currently if you want to sync that PR, you have to switch tabs back to the PR, copy the URL from the address bar, and paste it into the text field in the participate.whatwg.org page.

We should pass the PR number in the query string, and use that to pre-fill the textbox, so that you can just click "Update" without the switch-tabs-copy-paste workflow.

After #7, GitHub IDs are getting some validation. But we could go further and probe the GitHub API to ensure they actually exist as well. This removes some work from those doing the later validation.

We should allow entering with or without the @ but normalize them in the database to have no @. See whatwg/participant-data@9007793#diff-945c4feba40be6bc42659b8a2421c0ce for an example pre-this-change.