Property:Contains text
A
[[Access_Policy]] for
- Server shell access : root, user
- Git repo access: admin, maintain, write, triage, read
- email accounts: admin@ noreply@
- Mastodon Admin portal
- Mastodon @admin account
- Mastodon @techwg account
- Sendgrid
- Loomio
- Wiki
- DNS (neuromatch.social)
- Discord mod chat : discord roles until we move away from discord
Based on the access policy we decide, we would need to update access and note that on this page: https://wiki.neuromatch.io/Administrators +
great! let me plant a bookmark on the wiki to remind me to fill in this information when I get internet at my new place & can edit it. [[Accessibility#Disabling Motion]]
[[Discord#Accessibility]] +
[[Tech WG/Ops Diary#22-12-16 Upgrading Linode Ram]] Following the instructions to
* [[Resizing Linode]] [[Linode]]: https://www.linode.com/docs/guides/resizing-a-linode/
* [[Mastodon/Admin#Shutdown]]: https://docs.joinmastodon.org/admin/migrating/ from the migraing docs +
@here [[Announcements]] hello #neuromatchstodon membies
So far [[Jonny]] and [[Manisha]] have been doing most of the admin and moderation work in cooperation with the rest of the instance members.
We are excited to welcome new members joining our working groups!🎉 🥳
This has been a long time coming but #MastoDev extraordinaire [[Lina]] (who contributed to the Exclusive Lists PR that got merged upstream) is joining our [[Tech_WG]] 🙌
And the amazing [[El]] (who is one of the organizers of #Maystodon #JoinMastodonDay and #NeuroParty) is joining our [[Social_WG]] 🙌
Thank you both for your outstanding contributions ❤️ 🙏 +
[[Autofollow]]: Make all new accounts follow a a comma-separated list of account handles given in the .env file 🙂 +
B
ok [[Tech WG/Ops Diary#23-03-29]]: going to pull in dev branch and deploy to tha server: https://github.com/NeuromatchAcademy/mastodon/pull/13
I thought this had fetch all replies in it but i need to rebase it and also now that we know how to write them i want to write some tests....
It does have [[Better Code Blocks]] in it from <@485848481995423755> : https://github.com/NeuromatchAcademy/mastodon/pull/9
wish e luck +
C
NMA is from July 10-28, [[Climatematch Academy]] [[CMA]] is for 2 weeks from July 17-28. Not sure about NMC dates for this year. +
we've talked about this as well, being able to make the bot more granularly opt-in, as well as make some simple degeneracy rules like #CamelCase == [[Camel Case]] (actually proposed that probably to no result in masto here: https://github.com/mastodon/mastodon/issues/19992#issuecomment-1363496984 ) +
NMA is from July 10-28, [[Climatematch Academy]] [[CMA]] is for 2 weeks from July 17-28. Not sure about NMC dates for this year. +
<@863052667857534996> do y'all have anything like this for the pyopensci stuff? like a "make a feature branch off dev, make a pull request back to dev, during a code review, look for xyz" then we will also need stuff like how to do the merge and update the instance [[Hack Merging Policy]] [[Updating Mastodon]] [[Code Review]] +
Ah yes, this is a [[Consensus]] thing. I just updated the wiki page to explain a bit better: https://wiki.neuromatch.io/Mastodon/Governance#Voting
Yes, you can think of it analogously to a veto. Consensus refers both to making decisions that accommodate the needs of all members as well as consent - you should not be able to be coerced into consent by a bare majority of people. In more intimate consensus processes, a single person might be able to block a proposal. That becomes untenable in larger groups for sort of obvious reasons, hence the design of this governance system to have different proportional thresholds for different types of proposals, as well as division of decisionmaking power between working groups and the general membership.
A block means something different than voting in a few ways, including that blocks should be rare: consensus sort of inverts the decisionmaking process, where care should be taken to discuss with the membership and refine a proposal before, rather than after making the proposal - so in a majoritarian system one might make a proposal and make an argument in favor, people discuss in the comments and then make up their minds there. The purpose of requiring discussion beforehand is to make more space for everyone to craft the proposal in the first place, register concerns, etc. So if people are blocking a proposal, that is a sign that the process has failed (as opposed to in a majoritarian system that the proposal has failed).
Blocking also typically enjoins the person blocking to help remedy the reason for their block: if a proposal is being made in good faith, we assume that it is meeting some unmet need by the proposer/other members. If someone blocks a proposal, that will mean that it might cause them or the organization harm, but those unmet needs still remain - so it's basically like conflict res at that point. Ofc there are exceptions like not making marginalized ppl do additional labor, etc. +
Yes! Good question!!!!! Thats one of the basic [[Consensus]] questions - good for me vs. Good for the group. Good for both is ideal ofc, but "bad for me, good for the group" is the real meat of the problem. There's a couple of different flavors there. Is bad for me something thats actively bad, something that will have negative felt effects on me, or is it something that just isnt good for me, something I wont feel the positive effects of? Also, is "bad for me" a symptom of "bad for the group" in that the decision is exclusionary/the negative impacts predominately fall on a particular group? In this case, does being able to opt out alleviate concerns you have, or is there something larger you're objecting to beyond that? Few decisions are universally good for everyone, so were your concerns heard and weighed as part of the discussion? How that translates to a vote can be a little tricky/subjective, but in general if there are no active harmful effects, just absence of benefit for you then that would be a vote yes with caveat. Other consensus systems have a "stand aside" which is "if the rest of the group thinks this is good then I'll go with it, but I have some problem with the decision as a whole beyond how it impacts me" where a certain number of stand asides equal a block - doing something everyone feels lukewarm about is not great consensus. We could make abstentions mean that if that makes sense, altho an abstain means something slightly different ("I dont have enough information here but that wasnt the fault of the process" or "this us wholly irrelevant to me" or "I have some conflict of interest"). If you feel like this would have negative impacts on you that you feel like weren't seriously addressed during the discussion, or arent reflected in the outcome, then vote no.
Thats all my interpretation, not gospel or True, and the "meaning of votes" being somewhat up to interpretation and variable between systems is one of the things that makes consensus messy
so re: [[Stoplight]] and [[Cooldown]]s, [[Sidekiq#Cooldown]] tries to deliver something 16 times ( https://github.com/NeuromatchAcademy/mastodon/blob/eb24c0ad07c4137517e6bd37ebcc99d6e2b86797/app/workers/activitypub/delivery_worker.rb#L11 )
the delay rises exponentially (^4) with each retry. So eg by the 10th retry we're delaying an average of 208 minutes, and by 16 we're at 1365 (22 hours).
That delay uses sidekiq's `sidekiq_retry_in` method, which applies to each delivery task (ie. each status we're trying to push), but there is also an additional control flow tool Stoplight ( https://blog.bolshakov.dev/stoplight/ ) that applies per inbox URL (rather than per job). You start in a good (green) state. Each failure counts towards a threshold (10), after which it halts all jobs matching that inbox (red). After the cooldown period (60 seconds) it flips into a "yellow" state: if the next job succeeds, it flips back to green. If it fails, it goes immediately back to red.
That configuration seems sorta... pointless to me? if it only kicks in after 10 failures, then it'll only be halting after really long delays, right? it seems like that should be a high threshold with like a really long cooldown to me - if we haven't been able to deliver like 200 messages, then cooldown for like 6 hours (i'm not sure if receiving a message clears the stoplight) +
D
i think it would be cool if we could pay a member or two to hack on the instance!! we could take proposals on what ppl would like to see improved that guide what they are working on so we actually can resolve some of the many tiny things littering our [[Mastodon/TODO]] and maybe even one or two big things like finally doing [[DIY Algorithms]] or [[Nested Threads]] or whatnot.
[[Grants]] [[Mastodon/Grants]] +
re: [[PaperBot]] we also had talked about [[DOI Search]] and resolving urls to DOIs and embedding them in the [[JSON-LD]]. the DOI Search should actually be super easy if we do it by altering the hashtag regex. doing it by making it an additional search type would take a little more, as would doing automatic dereferencing, but all those sound like fun to me +
[[Mastodon/Tech WG#TODO]] [[Mastodon/Social WG#TODO]] Look into setting up Relays https://neuromatch.social/@manisha/109523786200081610 +
[[Mastodon/Tech WG#Done]] changed default email notifications in config/settings.yml to turn off new follow notifs and restarted services +
[[Tech WG/Ops Diary#23-01-20 Installed NTP to sync system clock]] This was done to resolve a 2FA issue involving Authy (a TOTP app) https://discord.com/channels/1049136631065628772/1049184335514828860/1065990577381974067 +
NMA is from July 10-28, [[Climatematch Academy]] [[CMA]] is for 2 weeks from July 17-28. Not sure about NMC dates for this year. +
[[Tech WG/Ops Diary#23-04-25]]: restarted systems services as we were hitting swap limits https://neuromatch.social/@manisha/110259466647197417 +