16:00:09 <achow101> #startmeeting 
16:00:09 <corebot> achow101: Meeting started at 2025-05-22T16:00+0000
16:00:10 <corebot> achow101: Current chairs: achow101
16:00:11 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:12 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:13 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:16 <lightlike> hi
16:00:16 <dzxzg> hi
16:00:18 <rkrux> hi
16:00:21 <hebasto> hi
16:00:22 <abubakarsadiq> hi
16:00:23 <sipa> hi
16:00:23 <achow101> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs jarolrod jonatack josibake kanzure laanwj LarryRuane lightlike luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
16:00:25 <hodlinator> hi
16:00:26 <johnny9dev> hi
16:00:31 <TheCharlatan> hi
16:00:41 <vasild> #here 
16:00:47 <cfields> hi
16:01:01 <achow101> There are 2 preproposed meeting topics this week. Any last minute ones to add?
16:01:02 <furszy> hi
16:01:03 <instagibbs> hi
16:01:04 <Murch[m]> Hi
16:01:09 <stickies-v> hi
16:01:38 <jon_atack> hi
16:01:43 <achow101> #topic Kernel WG Update (TheCharlatan)
16:01:58 <purpleKarrot> hi
16:02:05 <TheCharlatan> We've been having more directional conversations on the role of the library within the project, whether it should include the mempool, and whether the library could eventually be split out into a separate repository.
16:02:57 <TheCharlatan> I'll try to have some demo repositories / draft PRs open about these topics over the next few weeks.
16:03:03 <glozow> hi
16:03:15 <TheCharlatan> Other than that, looking for review on #32317 and #31382.
16:03:18 <corebot> https://github.com/bitcoin/bitcoin/issues/32317 | kernel: Separate UTXO set access from validation functions by TheCharlatan · Pull Request #32317 · bitcoin/bitcoin · GitHub
16:03:20 <corebot> https://github.com/bitcoin/bitcoin/issues/31382 | kernel: Flush in ChainstateManager destructor by TheCharlatan · Pull Request #31382 · bitcoin/bitcoin · GitHub
16:03:25 <TheCharlatan> that's all :)
16:03:26 <willcl-ark> Hi
16:03:40 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:04:27 <sipa> Getting some review on the next PR in the txgraph land, #31553 (3rd out of 4, after that the full cluster mempool is likely unblocked)
16:04:30 <corebot> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
16:04:48 <instagibbs> DoWork one is necessary I presume?
16:05:00 <sipa> yeah, that's the 4th one
16:05:06 <instagibbs> 👍ack
16:05:44 <sipa> I have also opened #32545, to replace the existing linearization algorithm with SFL (spanning forest linearization), a drop in replacement which apparently performs far better on hard clusters
16:05:45 <corebot> https://github.com/bitcoin/bitcoin/issues/32545 | Replace cluster linearization algorithm with SFL by sipa · Pull Request #32545 · bitcoin/bitcoin · GitHub
16:06:04 <sipa> There are some links to the delving posts with motivation and benchmarks.
16:06:27 <sipa> That's it from me.
16:06:41 <achow101> #topic MuSig2 WG Update (achow101, rkrux)
16:06:55 <achow101> #31622 has been merged, we're down to 2 PRs left in this project
16:07:01 <corebot> achow101: Error: That URL raised <Connection timed out.>
16:07:03 <achow101> The next PR to review is #31244 which has been getting some review over the past few weeks.
16:07:07 <corebot> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
16:07:11 <achow101> The final PR, #29675, is fully rebased and up to date if anyone wants to test that out or if it will help with reviewing 31244.
16:07:13 <corebot> https://github.com/bitcoin/bitcoin/issues/29675 | wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys by achow101 · Pull Request #29675 · bitcoin/bitcoin · GitHub
16:07:24 <achow101> #topic orphan resolution WG Update (glozow)
16:07:38 <glozow> I've pushed to #31829 and it is ready for review. It includes the multi-index reimplementation and the new eviction strategies we discussed at coredev. I think it's fine as 1 PR, but open to ideas on reorganizing/splitting.
16:07:41 <corebot> https://github.com/bitcoin/bitcoin/issues/31829 | p2p: improve TxOrphanage denial of service bounds and increase -maxorphantxs by glozow · Pull Request #31829 · bitcoin/bitcoin · GitHub
16:08:03 <sipa> cool, will look
16:08:32 <glozow> I talked to marcofleon today about adding a fuzzer for checking that 1p1cs always propagate regardless of spammy peers. But there are various tests etc on that PR as well
16:08:38 <glozow> sipa: thanks!
16:08:58 <glozow> that's it from me
16:09:27 <achow101> #topic QML GUI WG Update (jarolrod, johnny9dev)
16:09:32 <johnny9dev> This week we onboarded a new contributor, goqusan. He will be helping implement the QML components in the wallet views. He's starting with the receive page and added QR encoding. bitcoin-core/gui-qml#454
16:09:32 <johnny9dev> Christoph has been doing work on the Animations for the wallet and fixed the main transition easing with bitcoin-core/gui-qml#453
16:09:32 <johnny9dev> For me, I implemented the initialization states for the WalletQmlController and added the first instance of the Skeleton loading animation that Christoph proposed last week. bitcoin-core/gui-qml#454
16:09:32 <johnny9dev> This following week we'll be focused on getting bitcoin-core/gui-qml#450 mergable, implementing more of the Receive page, and adding input validation and error strings on to the Send page.
16:09:34 <corebot> https://github.com/bitcoin-core/gui-qml/issues/454 | Add QRImageProvider by goqusan · Pull Request #454 · bitcoin-core/gui-qml · GitHub
16:09:35 <corebot> https://github.com/bitcoin-core/gui-qml/issues/453 | Change PageStack easing type to InOutCubic by GBKS · Pull Request #453 · bitcoin-core/gui-qml · GitHub
16:09:36 <corebot> https://github.com/bitcoin-core/gui-qml/issues/454 | Add QRImageProvider by goqusan · Pull Request #454 · bitcoin-core/gui-qml · GitHub
16:09:37 <corebot> https://github.com/bitcoin-core/gui-qml/issues/450 | Add Multiple Recipients option to the Send form by johnny9 · Pull Request #450 · bitcoin-core/gui-qml · GitHub
16:10:27 <achow101> #topic project-related MSVC bug reports (hebasto)
16:10:35 <hebasto> Hi everyone! This is a short announcement.
16:10:40 <hebasto> To compile Bitcoin Core on Windows, there is currently only one supported option: MSVC.
16:10:45 <hebasto> As with any other compiler, the development process exposes regressions and new bugs in MSVC.
16:10:50 <hebasto> However, the process of improving MSVC, from reporting an issue to applying a fix, differs significantly from that of open-source compilers.
16:10:56 <hebasto> To improve our chances, I encourage anyone with a microsoft account to consider upvoting issue reports related to Bitcoin Core.
16:11:01 <hebasto> Here is a link to current issues, as well as some that have been closed: https://gist.github.com/hebasto/aa42915f88faa4a0ee02655bb55ee624
16:11:07 <hebasto> That's it. Thank you!
16:11:51 <sipa> Does mingw-w64 building not work on Windows?
16:12:10 <fanquake> You could just use that with the windows subsystem for linux yes
16:12:13 <hebasto> from within WSL
16:12:31 <achow101> but not natively with like cygwin or similar?
16:12:55 <fanquake> I'd encourage devs to do that in any case, so they are actually testing what we are shipping to users
16:13:49 <hebasto> we tested only MSVC native builds
16:13:58 <gmaxwell> If it was good enough for Satoshi... ;)
16:15:15 <achow101> #topic Statement on transaction relay policy (sipa)
16:16:01 <sipa> Hi.
16:16:21 <cfields> 👋
16:16:38 <sipa> I've written a short statement about the relation between Bitcoin Core developments and transaction relay policy, with the help of darosior and glozow
16:16:44 <sipa> https://gist.github.com/sipa/2521731e65ba779e3ce9f9305c6a538c
16:17:50 <achow101> planning to post to the website?
16:17:56 <sipa> I think it would be useful to publish something like this, possibly on the bitcoincore.org website if enough people agree
16:18:04 <sipa> but i'm open to hearing opinions
16:18:04 <darosior> Ack.
16:19:12 <achow101> will review
16:19:17 <gmaxwell> I couldn't remember if the project had every blocked a widespread active use.  The closest I could find is the dust limit stuff, but that seemed to go in after the penny dust had pretty much stopped AFAICT.
16:19:25 <gmaxwell> s/every/ever/
16:19:51 <stickies-v> very nice statement, will think of suggestions but ack for me too, thank you all for writing this up
16:20:04 <sipa> So, what do people think... have a short period for comments, and then ask who would be willing to put their name under it?
16:20:13 <dzxzg> "Within transaction relay, this may include adding policies for DoS protection and fee assessment, but not blocking relay of transactions that have sustained economic demand and reliably make it into blocks." I agree with this, but it seems to beg the question, how is demand weighed against DoS potential?
16:20:38 <sliv3r__> nice statement
16:20:46 <sipa> dzxzg: thankfully not a question i feel like we've had to answer yet, but a day may come
16:21:04 <instagibbs> DoS here doesn't mean usage of blockspace you don't like, but cpu/memory/etc
16:21:23 <gmaxwell> in any case, I think it's a very nice statement, and it feels very much in the tradition of the values I always understood coming from the project.
16:21:26 <sipa> right, exactly
16:21:29 <instagibbs> may be important to spell that out
16:21:33 <achow101> sipa: maybe a week for comments, and next week we can discuss posting to the website and who wants to put their name on it?
16:21:37 <fanquake> I'm not sure that having a list of names below is going to be beneficial, or is actually needed?
16:21:43 <darosior> sipa: re what do people think, maybe open a PR on the website for comments?
16:21:44 <jon_atack> fanquake: agree
16:21:55 <jon_atack> sipa: well done
16:21:59 <glozow> I think this can be opened as a PR to the website
16:22:21 <TheCharlatan> "> Note that this is not condoning non-financial data block space usage." this is what the issue seems to boil down to for users of Bitcoin Core, but I feel like this is not clear enough.
16:22:41 <sipa> glozow: right now? that would make suggesting corrections easy
16:22:43 <abubakarsadiq> nicely written, ack
16:23:18 <sipa> TheCharlatan: happy to hear ideas on making it clearer, but i'm also weary of going into too much detail
16:23:20 <glozow> sipa: I think so, given people are writing their comments here for specific lines. Perhaps worth doing this review process on the PR
16:23:25 <darosior> I would say yes because i don't see how waiting before opening the PR to the website would help
16:23:26 <dzxzg> instagibbs: Sure, whatever you take it to mean, the question would still stand. What if bare multisig outputs were to become popular? But I agree with sipa that maybe this question can be postponed for if/when it arrives
16:23:54 <fanquake> (if nobody wants their name attached, would we post it anyway? I'd like to think yes, if it represents the software we are shipping)
16:23:59 <glozow> dzxzg: I don't think bare multisig is a good example of DoS vs demand. Perhaps gigantic transacttions?
16:24:03 <gmaxwell> dzxzg: those don't fall under the dos banner (uh except related to sigops limit?)
16:24:06 <instagibbs> dzxzg bare multisig isn't a DoS (except for jank sigops counting), but sure if some new thing came up it would have to be weighed independently
16:24:13 <gmaxwell> instagibbs++
16:24:14 <sliv3r__> won't it end up an open PR like datacarriers' ones?
16:24:26 <gmaxwell> dzxzg: DOS obviously means to me things like quadratic hashing.
16:24:35 <instagibbs> like, if dust was being completely ignored (eep)
16:25:00 <sipa> dzxzg: bare multisig is standard (up to 3 pubkeys), but even if bigger multisig were to become common, my personal opinion would be to relax the policy - it's not DoSy in any way, only (perhaps subjectively) dumb
16:25:20 <gmaxwell> dzxzg: the closest to 'usage' I see DOS going might be dusting attacks. but generally I expect DOS to mean memory/algorithimic non-linearities.
16:25:23 <dzxzg> I thought bare multisig had a DoS issue, my mistake.
16:25:26 <instagibbs> block building gets annoying, as certain pools have found 😬
16:25:32 <gmaxwell> sipa: except for sigop counting.
16:25:37 <darosior> The question of DoS is interesting and i remember discussing it with some other contributors, but debating it now is off topic i think
16:25:44 <sipa> ah, and bare multisig of course has higher UTXO set impact
16:25:51 <sipa> that's perhaps a legitimate concern
16:26:05 <sipa> yeah, seems a bit of tangent today
16:26:11 <achow101> fanquake: I think the point of having individual names is because it should be perceived as a statement made with group support. possibly there are contributors who disagree with it and would not want their name to be on it, which would be less clear if there was not a list of names attached?
16:26:13 <gmaxwell> sipa: because dumb consenssus rules count sigops in OUTPUTS...
16:26:17 <Murch[m]> sipa: Especially due to its use for stamps and them getting spent at an uncommonly low rate
16:26:24 <gmaxwell> I actually think clarifying dos would be nice and important, but it might not be possible.
16:26:28 <dzxzg> Sure, I didn't mean to debate it, I was just sharing a question that I had reading the document, sorry for pushing off-topic
16:26:43 <instagibbs> gmaxwell ++ yeah just saying
16:26:43 <stickies-v> attaching names could be powerful but only if a large number of contributors are willing to do so, otherwise it could have the opposite effect
16:26:44 <gmaxwell> The first three alternatives I considered were worse.  "to address vulnerablities in the software or protocol" -- worse.
16:26:47 <fanquake> achow101: right, but if you end up with, for example, 4 names, that'd be a weird thing to post
16:26:47 <sipa> dzxzg: it is a good question, and i don't know the answer :)
16:26:48 <achow101> and I do think that if no one wanted to put their name on it, we wouldn't post it to the website
16:27:12 <Murch[m]> fanquake: I think there would be more than four names.
16:27:17 <glozow> fwiw I don't think the goal of this post is to prescribe what policy is for, I think it's just a statement to clarify a general intention to remove certain kinds of policy and why
16:27:29 <instagibbs> (or add)
16:27:38 <achow101> fanquake: yeah, there's definitely a threshold
16:27:38 <stickies-v> i'm supportive of adding my name, with the only caveat that we probably don't want to create too much precedent of having to sign off blog posts by contributors that support it
16:27:39 <Murch[m]> Happy to sign, fwiw
16:27:45 <fanquake> Murch: sure, but it's not clear what the threshhold is
16:28:04 <sipa> stickies-v: there is precedent, though very rare, and quite long ago
16:28:05 <gmaxwell> I hope there aren't significant contributors that disagree with this, if there are that should be hammered out (hammer mostly to be applied to contributor). :P
16:28:10 <achow101> also, having names would allow other people not necessarily involved in the project be able to endorse it as well
16:28:19 <jon_atack> re names, it could have consequences for those who add (naming and shaming) and for those who do not (didn't show support)
16:28:26 <darosior> I am happy to put my name on it but i agree with fanquake that it's not necessary. This what the project has always done and published binaries implementing this vision, i think it's fine to have it spelled out without necessarily stating who agrees explicitly or not
16:28:28 <rkrux> +1 for opening a PR - I'd review it, don't mind signing it
16:28:32 <fanquake> gmaxwell: that's kind of why I think the names are redundant
16:28:33 <cfields> achow101: I don't see anything I disagree with, but I also don't feel as though my signature adds any value here. I'm not sure individual names are necessary.
16:28:36 <gmaxwell> achow101: maybe better to just have another thing where people can lodge their support.
16:28:37 <jon_atack> omitting the names would avoid that
16:28:48 <fanquake> if people didn't agree, we'd have a PR, with enough ACKs, to change the software
16:28:57 <fanquake> and then the project would ship something different
16:29:17 <fanquake> If that's not the case, then what we are shipping represents the views of the project
16:29:28 <cfields> yeah, releases with policy changes don't come with statements/signatures :)
16:29:31 <fanquake> so it seems like any statement on the website, can be from the project, collectively
16:29:36 <Murch[m]> I’m also fine with presenting this as the view of the project
16:29:56 <stickies-v> the only reason in this case i'd be supportive of adding names is that it seems some people have a perception of maintainers / some contributors being almighty, and adding names helps show that it's not just a cabal pushing this but has widespread support among contributors
16:30:04 <darosior> fanquake: +1
16:30:14 <glozow> I also don't know if signatures are worth putting - people who want to personally endorse it can post it on social media? I think this post can follow our typical governance process for things that go onto the website. If people are strongly opposed then maybe we can have a conversation about something more granular than on/off website.
16:30:19 <achow101> stickies-v: yes, that
16:30:19 <stickies-v> but agreed with fanquake that it absolutely shouldn't be necessary
16:30:20 <gmaxwell> I can say that in the little contribution I've been doing in public outreach I'd like to be able to say that it went in without any opposition from the regular contributors.
16:30:30 <sipa> i feel there is a bit of a philosophical difference, in that releases represent the contributors' agreement at this very moment, while a post like this is a longer-term vision - and it's good to recognize that it's still a vision of specific people, and the set of people can change over time
16:30:36 <cfields> maybe fanning the flames, but something like this could potenially be PRd to Core as a guideline, and referenced/copied on the website for visibility.
16:30:43 <Murch[m]> And the threshold thing cuts the opposite way. If a couple minor contributors disagree, would we still publish etc?
16:30:52 <gmaxwell> cfields+1.
16:30:58 <gmaxwell> Murch[m]: they can also be asked to leave.
16:31:12 <gmaxwell> There is nothing wrong with people having a different vision!
16:31:37 <darosior> sipa: people's vision change, i don't think why we should expect a blog post to reflect someone's future vision more so than a binary
16:32:01 <gmaxwell> presumably if this understanding gets change the document should be amended/marked historical.
16:32:09 <lightlike> gmaxwell: why would they be asked to leave - there is nothing wrong with people withing the project having a different vision imo
16:32:11 <glozow> there can be a sentence saying "this only reflects the views of the *current* contributors" etc
16:32:41 <instagibbs> If your work doesn't touch relay (most don't), I don't know why it would be an issue
16:33:06 <gmaxwell> lightlike: sometimes, sometimes not! depends on their approach. e.g. having a different view is fine, but not if it's in the form of being obstructionist. Some people historically around the project have had difficulty with that.
16:33:11 <darosior> lightlike: depends on the compatibility of their vision, the specific things they disagree with, etc.. It's a case by case basis and in any ways i think someone that disagree with everybody else would leave without needing to be asked
16:33:21 <gmaxwell> hahaha
16:33:23 <sliv3r__> glozow: that + the date I think would work
16:33:41 <gmaxwell> but anyways, I apologize for starting a tangent.
16:33:46 <achow101> the point of having names is to shape how people will perceive the post, and I think that having the names of people who have not been actively participating in the discussion would help bolster the point that it is actually an opinion of many people in the project, not something being "forced" onto the project
16:34:06 <achow101> (and it seems highly likely that people not actively participating in the discussion would put their names on it, based on this discussion)
16:34:15 <Murch[m]> darosior: If only ;)
16:34:27 <gmaxwell> unfortunately most of the public has no idea who many people are, so unless you're gonna list them along side git blame LOC percentages...
16:34:29 <glozow> I'm a little wary of enumerating the people that twitter should channel hatred towards
16:34:46 <jon_atack> glozow: yep
16:34:49 <gmaxwell> (As I learned when public comments where accusing me and bluematt of having no idea of how compactblocks works... :P  )
16:34:56 <sipa> gmaxwell: hahaha
16:35:36 <darosior> I don't think having names is a good idea, but i also don't feel strongly. Whichever the author chooses.
16:35:39 <achow101> I think it's also not a good assumption to expect people to understand how ACK/NACKs work with merging changes to both the software and the website
16:36:12 <sipa> gmaxwell: i think you're right in that "being able to say that it went it without opposition from regular contributors" is important, perhaps more important than having actual names on it
16:36:14 <instagibbs> names could also be on the PR via ACK, then not on website, halfway 🤷
16:36:19 <Murch[m]> gmaxwell: To which you obviously replied "Do you have any idea who I am?"
16:36:45 <gmaxwell> sipa: right I mean that's the point that I think would matter in my discussions.
16:37:13 <sipa> ok, will open PR on website, without list of signatories for now, but can be discussed further there
16:37:14 <gmaxwell> Murch[m]: I really try to not do that ever. holy crap. what a gross thing to do.  I did one time say "don't you know who HE is" pointing at pieter, however. :P
16:37:29 <Murch[m]> sorry, that was a joke about Charles Hoskinson
16:37:37 <sipa> The first of his name.
16:37:40 <darosior> lol
16:37:40 <gmaxwell> oh really hah
16:37:41 <instagibbs> Murch[m] oh you need metamask help??
16:37:45 <instagibbs> dm me
16:37:51 <ajonas> instagibbs: To better anticipate objections (if any), did you get pushback from your write up? Obviously not the same thing, but you were asked to do that for the group.
16:38:06 <instagibbs> ajonas we didn't converge on a unified voice in our little group
16:38:08 <glozow> I think we should review wording on the PR, not do signatures, aim to get a lot of (concept) ACKs, perhaps more than normal (text is easier than code review right?), and then merge when we have rough consensus. The people who ACK'd are supporting it in a public place, which imo is enough.
16:38:28 <cfields> People will most definitely conflate the a signature on statement with an ACK to the policy changes btw. The former I feel qualified to do, but not the latter. I agree with the guiding principles laid out in the post, but lack the expertise to judge the specific changes.  So I'm +1 for no names.
16:38:28 <instagibbs> ajonas it's also possible I'm just weak willed and gave up early
16:38:39 <ajonas> instagibbs: that's tracks
16:38:42 <gmaxwell> so a problem you will face on the PR is that a lot of total randos will show up and throw mud at it unproductively.
16:38:55 <gmaxwell> And then there will be false implications that the project didn't broadly support it.
16:39:12 <gmaxwell> Sorry I don't have a solution, but I almost guarentee this will happen.
16:39:37 <darosior> Agree with what glozow suggests
16:39:44 <achow101> gmaxwell: put a comment at the top "if you don't contribute to this project, your comment will be deleted"
16:39:53 <sipa> gmaxwell: sgtm
16:39:56 <sipa> eh
16:39:59 <sipa> glozow: sgtm
16:39:59 <gmaxwell> can you limit a PR to project members? (obviously contributors are wider...)
16:40:12 <glozow> perhaps unpopular opinion, but maybe the website repo should have stricter contribution requirements than the bitcoin/bitcoin repo
16:40:27 <glozow> achow101: yeah or that
16:40:36 <achow101> there is a roundabout way to make conversation locking let contributors comment, but it requires giving everyone write access
16:40:42 <gmaxwell> glozow: historically website has had some good help from people who aren't developers, though I agree  with that view.
16:40:45 <gmaxwell> ugh, damn github.
16:40:58 <achow101> for the website, I think that's probably fine though since deploying the site has several extra steps that happen off github
16:41:16 <glozow> gmaxwell: yeah agree. but I think it's perfectly reasonable that this particular PR only seeks input from regular contributors
16:41:29 <glozow> seek*
16:41:38 <Murch[m]> And just like predicted, the brigading now lead to development channels becoming more permissioned :p
16:41:40 <achow101> we can also turn on the "have contributed to this repo before" limit, but that actually probably excludes many regular contributors
16:41:54 <sliv3r__> what about the statement without names + pgp signatures?
16:41:59 <gmaxwell> glozow: yes exactly. It's their statement not anyone elses. supportive comments (like mine!) I hope are welcome but could be channeled via recent contributors.
16:42:29 <achow101> sliv3r__: that's the same thing, but with more friction?
16:42:36 <Murch[m]> sliv3r__: That’s just extra work on the person that writes the scathing investigative breaking news Twitter article :p
16:42:48 <glozow> Murch[m]: I get what you're saying and generally agree, but this post isn't development at all. It's contributors agreeing on wording!
16:43:06 <Murch[m]> glozow: Fair enough
16:43:28 <Murch[m]> Also, I think it would be easier to lock it to contributors than to delete non-contributors
16:43:38 <fanquake> I've found the setting that should limit the interaction to people in the frequent contribs group
16:43:41 <Murch[m]> Maybe "easier" is the wrong word, but less abrasive
16:43:44 <fanquake> Don't think we need to hand out write access
16:43:51 <achow101> fanquake: which setting?
16:43:55 <gmaxwell> The delete has some bad effects which I can discuss later cause its a total tangent.
16:44:23 <gmaxwell> sipa: authors could also just offer to forward on any comments from contributors that have issues getting to the repo.
16:44:29 <achow101> fanquake: oh, limit to prior contributors does include org members, so I guess that would be fine too
16:44:36 <fanquake> achow101: we should be able to restrict to collaborators, where collaborators are in frequent contributors
16:44:47 <achow101> fanquake: collaborators == write access
16:45:04 <achow101> (it's stupid, and everyone gets tripped up on this)
16:45:13 <darosior> Create a Github team, just a third group for maintainers to manage and keep in sync /s
16:45:21 <fanquake> i can add that team with read access?
16:45:26 <fanquake> No write access needed
16:45:37 <achow101> fanquake: I don't think they count as collaborators to github
16:46:25 <fanquake> 1 sec
16:46:46 <achow101> i think that's a repo-wide setting
16:46:48 <fanquake> can everyone still interact here: https://github.com/bitcoin-core/bitcoincore.org
16:47:16 <fanquake> I've added frequent collaborators as a team, with read access, and restricted interaction on that repo to only collaborators
16:47:18 <darosior> fanquake: yes https://github.com/bitcoin-core/bitcoincore.org/pull/1135#issuecomment-2901911556
16:47:26 <achow101> fanquake: that setting includes organization members too
16:47:35 <gmaxwell> I feel bad for the tangent was there anything else for the agenda? github gnoming can probably be done right after.
16:47:47 <sipa> gmaxwell: it was the last agenda item
16:47:47 <achow101> gmaxwell: yes, good point
16:47:52 <achow101> Any other topics to discuss?
16:48:50 <achow101> #endmeeting