19:00:27 <achow101> #startmeeting 
19:00:27 <core-meetingbot> Meeting started Thu Jan 19 19:00:27 2023 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:27 <core-meetingbot> Available commands: action commands idea info link nick
19:00:41 <achow101> #bitcoin -core-dev Meeting: achow101 aj amiti ariard b10c BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd
19:00:41 <achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:01:19 <sipa> hi
19:01:21 <_aj_> 3~hi
19:01:24 <brunoerg> hi
19:01:35 <instagibbs> hi
19:01:40 <furszy> hi
19:01:51 <achow101> There are two preproposed meeting topics: code of conduct (achow101), libsecp256k1 release schedule (sipa). Any other topics to add to the list for today?
19:02:17 <ariard> hi
19:02:21 <lightlike> hi
19:02:30 <achow101> #topic High priority for review
19:02:31 <core-meetingbot> topic: High priority for review
19:02:38 <achow101> https://github.com/orgs/bitcoin/projects/1/views/1 Anything to add/remove/merge
19:02:57 <jonatack> hi
19:03:40 <sipa> Can I have #25653 ?
19:03:41 <gribble> https://github.com/bitcoin/bitcoin/issues/25653 | HTTP Error 404: Not Found
19:04:01 <achow101> sipa: it doesn't exist?
19:04:11 <sipa> Wow, my brain's copy-paste buffer is terrible. I mean #26153.
19:04:13 <gribble> https://github.com/bitcoin/bitcoin/issues/26153 | Reduce wasted pseudorandom bytes in ChaCha20 + various improvements by sipa · Pull Request #26153 · bitcoin/bitcoin · GitHub
19:04:41 <achow101> added
19:04:47 <sipa> dank
19:06:34 <lightlike> it seems that https://github.com/orgs/bitcoin/projects/1/views/1 and the new https://github.com/orgs/bitcoin/projects/5/views/1 have  diverged - maybe we should just use one of the two?
19:07:24 <achow101> I viewed the new one as a more free form where anyone could add whatever they wanted
19:08:42 <lightlike> oh, ok
19:09:06 <achow101> maybe _aj_ had a different usage in mind when he brought up the idea?
19:09:16 <_aj_> just added the missing ones from high prio to pr statuses
19:11:19 <achow101> #opic code of conduct (achow101)
19:11:27 <achow101> #topic code of conduct (achow101)
19:11:27 <core-meetingbot> topic: code of conduct (achow101)
19:12:34 <achow101> I wanted to get some thoughts on whether a code of conduct (not necessarily the one proposed in #26890) is something that people think we should have in this project
19:12:36 <gribble> https://github.com/bitcoin/bitcoin/issues/26890 | Introduce a Code of Conduct by achow101 · Pull Request #26890 · bitcoin/bitcoin · GitHub
19:12:42 <b10c> hi
19:15:23 <ariard> achow101: have you get feedback on how a code of conduct could be opposed legal binding to contributors ?
19:15:55 <instagibbs> from you ariard I think :P
19:16:15 <_aj_> instagibbs: (achow101 was going to get lawyer-ish feedback, i think)
19:16:20 <achow101> ariard: not yet. ajonas is helping me with finding some lawyers to look at it
19:16:37 <achow101> should have something next week I think?
19:16:54 <ariard> well i checked the french law on the legal binding of internet code of conduct...and it turns out you have cases where they have been recognized legal binding
19:17:28 <ariard> in matters of civil law and spamming-only -- though still it means code of conduct have been included in the law norm hierarchy which isn't good ihmo
19:17:38 <MacroFake> No opinion on that, but I think we can just continue as before with (temporary) bans. No one seems to have complained about how things were done in the past. And the only change of the CoC.md would be that there are warnings for less severe violations, so maybe just do that in the future without the md file?
19:18:14 <ariard> achow101: the hard thing you will need probably lawyer opinions...from well all the juridctions where we have contributors :/
19:19:08 <instagibbs> MacroFake, I don't think temp bans are happening fast enough, just my humble opionion ofc
19:19:25 <achow101> MacroFake: we've taken actions on the obvious stuff like spam and threats of violence, but there are some behaviors that I think warrant action but are less obvious and potentialy more contentious, so a CoC would help us set the line for those
19:20:02 <achow101> more contentious in that taking action can be contested if it isn't written down as something that we don't think is appriopriate conduct
19:21:24 <_aj_> it can be contested anyway; as long as the people doing the moderating (and most normal contributors) are in agreement, it's fine?
19:21:53 <kanzure> i agree with some of the comments advising high levels of caution before deciding to implement a code of conduct programme
19:23:19 <achow101> _aj_: how would we do that though? Have a topic in the meeting of "proposal to ban X"?
19:24:12 <sipa> I have little opinion, fwiw. I do see some of the problems that may merit different moderation and policies; I don't know whether a CoC is the right way to address those, but also don't oppose it.
19:24:12 <kanzure> is your concern about a ban of a contributor looking like a unilateral action which might be subject to backlash/headaches that you would like to be personally protected from
19:24:14 <MacroFake> achow101: The people that can ban (+ maybe some maintainers ) could discuss a warning/ban?
19:24:30 <achow101> kanzure: yes
19:24:39 <_aj_> achow101: have the moderators moderate things quickly; have a signal group for the moderators to get quick feedback; be prepared to undo things if you go too far
19:26:37 <_aj_> achow101: maybe have a wiki page where you document what people should(n't) be doing if reasonable people seem to be getting confused
19:26:41 <kanzure> well, you can't be everything to everyone, and it's naturally okay for some people to just not want to work together
19:28:39 <achow101> _aj_: I guess so
19:29:15 <achow101> in terms of who can moderate, right now it's basically just the maintainers, github does have Moderator position though
19:31:08 <achow101> if anyone wants that permission, we could have a discussion about it like we do for maintainership?
19:31:57 <kanzure> https://www.lesswrong.com/posts/tscc3e5eujrsEeFN4/well-kept-gardens-die-by-pacifism
19:33:47 <achow101> seems like there isn't much else to say on this topic
19:33:55 <achow101> #topic libsecp256k1 release schedule (sipa)
19:33:55 <core-meetingbot> topic: libsecp256k1 release schedule (sipa)
19:34:04 <sipa> Just a short announcement mostly.
19:34:49 <sipa> In the libsecp256k1 meeting monday we decided to aim for a roughly every-3-months release schedule, every second one of which synchronized with the bitcoin core releases (~1 month before feature freeze).
19:35:06 <sipa> So the next one would be early march.
19:35:31 <achow101> sipa: will the versioning be sane?
19:35:44 <sipa> semantic versioning
19:35:55 <sipa> we releases 0.2.0 in december, in case you missed it
19:35:59 <sipa> *released
19:36:34 <sipa> https://github.com/bitcoin-core/secp256k1/blob/master/CHANGELOG.md
19:36:38 <achow101> is the idea that we would do a subtree update just before feature freeze every release?
19:36:50 <sipa> or at least, have the opportunity to do so
19:36:53 <sipa> yeah
19:37:51 <sipa> so far libsecp256k1 pulls have mostly been "enough useful stuff has accumulated"
19:38:01 <sipa> but now we also have a changelog etc, so it should be easier to reason about that
19:38:25 <achow101> doing it on a regular schedule seems reasonable
19:39:00 <sipa> yeah, we considered doing it more feature based ("there is enough useful stuff"), but having regular releases may be beneficial for contributions too
19:39:24 <sipa> but on the other hand, the overhead of a release is so low that we don't need to go to once-every-6-months either
19:39:50 <sipa> not that much to discuss, just wanted to announce it here, and if people have comments/opinions, feel free to reach out
19:40:00 <_aj_> sounds great
19:40:04 <sipa> for now we'll just see how it goes
19:40:04 <achow101> cool
19:40:06 <MacroFake> Will previous releases receive bugfixes?
19:40:33 <MacroFake> If yes, then you may underestimate the overhead, as it scales with the number of supported previous releases
19:40:39 <sipa> MacroFake: Yes, that's the plan. Though we have little experience with bugs... *humblebrag*
19:41:31 <_aj_> i'm sure you could do a call for contributors if you want more experience with bugs?
19:42:30 <sipa> There is one open question I now think of, which is how to deal with Bitcoin Core PRs that depend on new features (specifically, #23432 currently).
19:42:34 <gribble> https://github.com/bitcoin/bitcoin/issues/23432 | BIP324: CKey encode/decode to elligator-swift by dhruv · Pull Request #23432 · bitcoin/bitcoin · GitHub
19:43:25 <_aj_> new released features that just need a subtree update?
19:44:22 <sipa> Yeah, I guess it just needs some synchronization.
19:45:18 <_aj_> once there's a concept ack'ed pr that needs the subtree update, put the subtree update in high-prio?
19:45:37 <achow101> I think it's fine to just update the subtree ad-hoc if we really need it
19:45:42 <sipa> yeah
19:46:07 <_aj_> oh, as opposed to only updating the subtree just before a bitcoin release? yeah
19:48:22 <achow101> any other topics to discuss?
19:50:17 <achow101> #endmeeting