03:29
<MikeSmith>
For GitHub, anybody know of a tool that can show a graph of contributor growth for a particular repo?
03:29
<MikeSmith>
I mean, show how many new contributors were added each week (for this year, last year, etc.)
03:30
<MikeSmith>
Context is that for https://github.com/mdn/browser-compat-data, I think we have been getting new contributors at the rate of at least one or two a week — but I don’t know how to confirm that
03:30
<MikeSmith>
last time I remember checking, I think we had 722 contributors there, and now today we already have 727
04:02
<Krinkle>
MikeSmith: closest thing that comes to mind is git-shortlog which, if invoked with a summary "one author per line + commit count", gives you back something where `wc -l` is the number of distinct contributors. If you then invoke this a couple times with limited date ranges (`main@{3 weeks ago}` etc.) you can get the total as of Jan 2020, then Feb 2020 etc and see how quickly it rises.
07:58
<annevk>
happy b-day zcorpan_ \o/
09:15
<MikeSmith>
Krinkle: thanks yeah so I may write a script to automate something like that. But it’d just be surprising to me if somebody else hadn’t already. It seems like something a lot of projects would want. A Google search doesn’t turn up anything at all though. But maybe I’m just not thinking of the right words
09:17
<MikeSmith>
..instead only lots of vanity stuff like https://github.com/sallar/github-contributions-chart for views of one’s own individual contributions
09:19
<jgraham>
It's possible that there aren't many projects using "number of new contributors" as a metric (or just that people made one-off scripts for that which they didn't release)
09:23
<annevk>
For HTML we looked at the total number of contributors at times, it seems it's at 262 now which is pretty cool
09:28
<jgraham>
I also remember this is hard to get right because there's usually some people with >1 email address and cases where the email address is mangled
09:28
<jgraham>
So just using the git data you need to do significant project-specific normalisation
09:29
<MikeSmith>
yeah the e-mail thing can be addressed using .mailmap
09:30
<MikeSmith>
but as far as maybe not many projects are using "number of new contributors" as a metric, it would seem odd to me for any project to not be interested in measuring project growth
09:31
<MikeSmith>
and number of unique contributors seems like an obvious thing to want to track over time, as an indicator of growth
09:32
<MikeSmith>
well also the rate
09:33
<MikeSmith>
I mean, the rate at which the project is getting PRs from new contributors
09:35
<annevk>
I dunno, sustained contributions are more interesting than the one-off fixes to me, but the one-off fixes are still nice
09:37
<annevk>
That is, with "good first issue" we attract a lot of contributors and can help people learn how to patch things, but it's rare for them to stay and tackle bigger things
09:41
<MikeSmith>
yeah good point
09:43
<MikeSmith>
but for a project like MDN the long tail of one-off fixes can grow pretty big and actually be more interesting
09:43
<MikeSmith>
part of the context for me for this now is that MDN content will be all be moving to github
09:44
<MikeSmith>
https://github.com/mdn/content/issues/117
10:15
<annevk>
benjamingr__: re https://github.com/web-platform-tests/wpt/pull/26472 I suspect smaug____ means dispatching another event from the listener that triggers another listener
10:15
<annevk>
benjamingr__: however, I'm not entirely sure what the tricky signal cases would be in such a setup
10:16
<annevk>
maybe the nested event's listener cancels a listener the outer event would have triggered afterwards?
10:18
<benjamingr__>
So I have a `foo` listener that adds a `bar` listener, dispatches a `bar` event and that `bar` listener calls `.abort()` which makes sure a second `.foo` listener is removed?
10:19
<benjamingr__>
I'm not entirely sure why that's tricky with regards to signals either - but if that's the case I'm happy to add such a test if you think it's a good idea to have one.
10:20
<annevk>
benjamingr__: might be best to wait for smaug____ to get in and answer
10:20
<benjamingr__>
ack
10:20
<annevk>
(but yeah, that's what I had in mind)
10:20
<MikeSmith>
talking with Dom right now and he pointed me to https://dontcallmedom.github.io/github-community-monitor/
10:20
<annevk>
benjamingr__: to be fair, I also did not anticipate Chrome's bug of capture no longer working
10:25
<smaug____>
benjamingr__: I was thinking playing with the same event type
10:25
<smaug____>
but nested events
10:25
<benjamingr__>
@annevk Me neither - I wouldn't have tested for it initially and only found it by reading the implementation code and going through the spec trying to find differences. I have no idea what other inconsistencies may exist in other browsers or how EventTarget is implemented there so I'm happy to add tests for things people think are worth testing.
10:25
<smaug____>
of course need to ensure the test doesn't end up to enless recursion loop
10:26
<annevk>
The penalty for not implementing signal quickly will be endless loops on WPT :p
10:27
<benjamingr__>
smaug____: Something like this? https://gist.github.com/benjamingr/f20d50ba6e02192debab93907a20f3ee
10:28
<benjamingr__>
Haha, yeah don't run it on stock chrome/firefox it will probably run into an endless loop ^^
10:28
<benjamingr__>
(also missing a dispatchEvent to fire things off at the end)
10:30
<smaug____>
the first event listener would add more listeners and dispatch nested event
10:31
<benjamingr__>
With the same event name?
10:31
<smaug____>
The key is that while an event is being dispatch and handled, another listener is added and another event is dispatched
10:31
<smaug____>
yes
10:34
<benjamingr__>
I pressed enter and my browser just froze in a really weird way ^^ serves me right - something like this smaug____ https://gist.github.com/benjamingr/7ca1c3e50d2961173f3d12fee4945e14 ?
10:34
<benjamingr__>
wait no that's a fork bomb lol
10:34
<benjamingr__>
The listener is added each time, no wonder it froze my browser
10:35
<benjamingr__>
The "outer" listener needs to be added with `once`
10:36
<benjamingr__>
ok, updated to once, is that what you had in mind?
10:38
<smaug____>
I guess that could work. Is does test some of the nested handling
10:42
<benjamingr__>
I'll add it then :] I'm happy to change the test (or other tests) - note I don't have a lot of (well, any really) experience authoring WPTs so feedback and improvement suggestions are definitely appreciated and feedback will be swiftly applied.
10:44
<smaug____>
it is also good to have some tests initially and then while implementing the feature one can add more
10:45
<benjamingr__>
sounds good to me :]
10:46
<smaug____>
Perhaps better to test that nested dispatching only if the browser supports signal as an option for addEventListener
10:49
<annevk>
I think it's fine, I'd really rather not do feature testing in tests, timeout exists
10:50
<benjamingr__>
ack, I think it will exit with a `RangeError` rather than do an infinite loop anyway
10:51
<smaug____>
RangeError?
10:59
<benjamingr__>
Yes, though that might be an implementation detail? I think that it pushes the next invocation on the call stack which eventually runs out of space so eventually you get a stack overflow
11:00
<benjamingr__>
That's what Firefox/Chrome do with the above code anyway, I haven't checked Safari
11:00
<annevk>
JavaScript only defines OOM for ArrayBuffer allocation, iirc
11:03
<annevk>
benjamingr__: you should add an assert after dispatching the final event (though prolly only run the assert when count > 5)
11:07
smaug____
finds some ancient test he had for recursion http://mozilla.pettay.fi/moztests/events/event_loop.html
11:07
<smaug____>
from pre-Chrome era
11:28
<shu>
annevk: i've been thinking about actually getting some normative prose in there about small allocation OOMs
11:29
<annevk>
shu: cool cool
11:29
<shu>
it's implied in this one non-normative note in the regexp section
11:29
<annevk>
heh
15:41
<zcorpan_>
Thanks, annevk!
16:57
<Krinkle>
MikeSmith: related - https://wikimedia.biterg.io/app/kibana , https://insights.lfx.linuxfoundation.org/projects/ojsf%2Fojsf-jquery/dashboard
16:57
<Krinkle>
but a lot more overhead, and might still not exactly give you that metric :)
16:58
MikeSmith
looks at Krinkle links
16:59
<MikeSmith>
ah nice
17:02
<MikeSmith>
Krinkle: added a comment at https://github.com/mdn/content/issues/117#issuecomment-730508435 with those links
17:06
<Krinkle>
The biterg one is open source (runs something called Grimoirelab). I would assume the LF one is open source as well, but I haven't yet managed to find its source
19:35
<zcorpan_>
https://css-tricks.com/using-details-for-menus-and-dialogs-is-an-interesting-idea/ - is this appropriate use of <details>? I was unsure first, but it doesn't seem wrong. Also wonder if any screen readers get confused, but assume it at least is accessible enough to be workable
21:50
<croraf>
If you check the the definition of "value" in the attributes table here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
21:50
<croraf>
it is just plain wrong?
21:52
<MikeSmith>
zcorpan_: it doesn’t violate any conformance requirements?
21:54
<zcorpan_>
MikeSmith: don't think so?
21:54
<zcorpan_>
<summary> has role=button as implicit role https://w3c.github.io/html-aria/#el-summary
21:54
<MikeSmith>
zcorpan_: yeah the markup doesn’t at least, as far as I can see
21:55
<MikeSmith>
croraf: what’s plain wrong about it?
21:56
<zcorpan_>
github uses <div> inside <summary>, but that could as well be a <span>
21:56
<MikeSmith>
croraf: it links to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#htmlattrdefvalue and what that says also does not seem plain wrong
21:56
<MikeSmith>
zcorpan_: yeah
21:57
<zcorpan_>
"The details element represents a disclosure widget from which the user can obtain additional information **or controls**."
21:58
<croraf>
MikeSmith, It says "Current value of the form control. Submitted with the form as part of a name/value pair."
21:58
<croraf>
This is not what value attribute is. It might be the initial value of the form control, but not the current value, which is the value that is submitted when the form is submitted.
22:00
<zcorpan_>
croraf: you're right. the description in https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#htmlattrdefvalue is more accurate
22:01
<MikeSmith>
croraf: OK, then sounds worth editing the article, or else using the Feedback link to raise a https://github.com/mdn/sprints/issues issue to request a fix
22:01
<croraf>
Even the thing you linked, the detailed description says in the first sentence: "The input control's value."
22:02
<croraf>
And in the next sentence "When specified in the HTML..." The thing that is specified in the HTML is the attribute, which is not the same thing as "value" property of the HTMLInputElement. So they are also confusing these 2 things.
22:08
<zcorpan_>
croraf: yes, it could certainly be clarified. please edit it :)
22:08
<croraf>
zcorpan_, thanks for confirmation
22:09
<zcorpan_>
np. thanks for checking!
22:16
<croraf>
I'm checking the select element HTML spec: https://html.spec.whatwg.org/#the-select-element
22:17
<croraf>
The only thing I see regarding the events is in the middle of that section, starting with: "When the user agent is to send select update notifications, queue an element task on the user interaction task source given the select element to run these steps:"
22:18
<croraf>
I don't see from that which events can "select" trigger and when.
22:20
<croraf>
Also I'm 99% sure that changing the "value" property using JS doesn't trigger any event, but where does this say in the spec.
22:29
<croraf>
I guess there are common events fired on all elements, like "click", "mouseenter" and similar described somewhere in the spec. And the particular events "input" and "change" denoted in this section.
22:29
<zcorpan_>
croraf: you can click the definition (the bold part) to get a list of references to that term
22:31
<zcorpan_>
croraf: the 3 cases are all result of user interaction, afaict
22:35
<croraf>
zcorpan_, aha, sorry, I skipped the paragraphs mentioning "multiple" but now I see that they say "If multiple attribute is absent..." :D
22:35
<croraf>
I think they explain my question.
22:47
<croraf>
Yes, these paragraphs explain the input and change events. I guess other events (like click) are handled in a common way as described somewhere for HTMLElements, because HTMLSelectElement inherits from HTMLElement.
22:50
<croraf>
This section https://html.spec.whatwg.org/#global-attributes mentiones global eventHandler attributes, but I haven't really found the section that describes how, when and which events are dispatched from HTMLElement