[01:13:57] hm [01:15:43] uh [01:15:46] 09 [01:16:25] ah finally [01:16:44] 09 hi [01:16:51] beans [01:16:56] 04lol [01:17:46] dasok [01:18:03] omg this client is so sick [01:18:43] xoChat, nice [01:18:49] never heard of it [01:19:09] how'd you know? [01:19:26] :) [01:19:41] magic [01:20:41] 04hi [01:20:49] ok this is so cool [01:21:13] just changing a setting ill brb [01:25:36] hey 08yellow03frogger [01:25:42] hey [01:25:59] Hello [01:26:10] agent that name is so clever tho [01:26:14] this here is a... how did i log in without having an account? [01:26:23] Bongo-Cat: I also have puppet-agent :P [01:26:30] but that's better suited for -offtopic [01:26:36] YellowFrogger: You don't need an account to use IRC [01:26:58] But an account is recommended as I can take your nickname, group it to my account and kill you via services if I desired to [01:27:30] my ip publicly ¯\_(🤯)_/¯ [01:27:43] YellowFrogger: Indeed, I can see your IP [01:28:15] "+ssh-agent> But an account is recommended as I can take your nickname, group it to my account and kill you via services if I desired to" that sounds a bit wrong if people don't know irc limbo :P [01:28:22] irritating. How do I get an account? without showing my ip [01:28:31] do /ns [01:28:40] like /ns register [01:28:43] or something [01:28:44] idk [01:28:59] YellowFrogger: your IP will always be visible via IRC, it's just the way it is which is why you may prefer to use a bouncer service [01:29:05] oh yeah [01:29:14] Bongo-Cat: I'm just telling him why it's advisable he registers an account [01:29:30] But indeed, do /ns register to get started [01:29:46] IRC is still a bit new to me, although I've been using it since late 2020 :P [01:29:55] understandable [01:30:07] and honestly, before that [01:30:09] and i don't see anyone's ip, only mine is visible, whyyy [01:30:19] most people have cloaks [01:30:24] YellowFrogger: because we have cloaks but you can use loopholes to bypass them [01:30:26] [[IRC/Cloaks [01:30:55] I know you can always trick services into returning a user's IP [01:31:09] I don't know if that's been patched yet though or if it's intended behavior [01:31:10] [[IRC/Group#Cloaks]] [01:31:10] https://meta.miraheze.org/wiki/IRC/Group#Cloaks [01:31:55] That's why I don't use it here, sorry. But I don't know how to create an account. [01:32:08] YellowFrogger: /ns register and follow the prompts\ [01:32:27] if you register, you can ask either Justin or John for a cloak [01:32:33] not me [01:32:40] NDKilla [01:32:49] furthermore, you have no privacy (as quoted by you that we can handle). [01:33:06] despite being quite fast [01:33:09] IRC is an old protocol, written a long time ago, it should be expected [01:33:43] IRC is pretty old [01:33:54] Older than me, IIRC. [01:34:02] anyway, this conversation is better suited for #miraheze-offtopic [01:34:08] Bongo-Cat: much older than you :) [01:34:41] damn 1988 [01:35:09] ssh-agent how do i rename myself? or exclude me? [01:35:17] YellowFrogger: /nick [01:35:26] ill go to #miraheze-offtopic [01:35:36] yeah, this is better suited for -offtopic [01:35:39] YellowFrogger: ^ [01:39:03] ssh-agent how do i hide my lP? [01:39:18] you cant necessarily hide it [01:39:25] you can request a cloak though [01:39:30] or use a bouncer [01:39:34] That too [01:39:56] Hello Excel! If you have any questions, feel free to ask and someone should answer soon. [01:40:19] note that that username is registered [01:41:44] when i left the server, my name disappeared from the users list. So I don't think will need to. [01:44:00] Hello Paralelepipedo! If you have any questions, feel free to ask and someone should answer soon. [17:25:43] @krrk this channel is a good place for questions [17:26:34] OK, will ask in here, thanks! [17:27:22] Is there a way that I can view all members belonging to a given group in MediaWiki? [17:27:42] Special:ListUsers [17:27:46] and then filter by groups [17:27:47] tick the boxes [17:33:16] That worked, thanks! [17:36:48] We only let members of our makerspace edit our wiki. We have a group called fcfl_members that has edit rights. We want to keep group in sync with our member list. What tools/extensions are available to help manage this? [17:37:22] We can have a Google Sheet that maps Miraheze username to email/real name, but it would be nice if this mapping could be managed by MediaWiki [17:37:58] Hello leilat! If you have any questions, feel free to ask and someone should answer soon. [17:38:10] It'd be great if we could see the verified email of every user in the fcfl_members group [17:39:03] That's not possible, unfortunately [17:39:05] The reception wiki must be shut down, immediately! [17:39:26] leilat: Why? [17:40:22] We are not going to shut them down, at all. Period. [17:40:30] something real bad must happen w/ them [17:41:15] leilat We are not going to shut them down just because you said so. [17:42:49] Aside from that, this is the umpteenth time someone has requested the wikis to be shut down, only for it to be declined. [17:57:01] Is there any way (an extension, maybe) that we can store metadata about users? E.g. when we add a user to fcfl_members, we attach a note tied to that user says "this user's real name is John Smith", and this note is only editable / viewable by administrators? [17:57:44] I guess one way to do that would be just a wiki page that lists users along with their real name. Is there a way to make such a page only visible to administrators? [17:58:43] I think it's not possible to have such a page, based on what I'm reading at https://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_viewing_of_certain_specific_pages [17:58:43] @krrk No links allowed. [17:58:43] [url] Manual:Preventing access - MediaWiki | www.mediawiki.org [17:58:48] Social Profile allows people to display their public name and such [17:59:11] You need to .auth to post links [17:59:19] ah cool will do that [17:59:19] Command sent from Discord by krrk: [17:59:20] .auth [18:01:35] Right, but we want to prevent the user themselves from editing this information, or (if it's their email) have it be verified [18:01:49] It sounds like we might have to use a Google Sheet to track wiki members. That's not too bad [18:02:05] weird guess, but take away edit rights on user namespace? [18:02:19] if it's possible [18:02:56] there is an extension that lock user pages to ne edit by anyone, except the user who owns it [18:03:49] Hmm that's an interesting idea. Although it might be nice for users to be able to create a user profile [18:08:17] Hello sali! If you have any questions, feel free to ask and someone should answer soon. [18:10:11] Shut down characters wiki and rename websites wiki to companies wiki? [18:11:28] wut [18:12:34] It violates content policy [18:12:37] Nice try leilat. But I already told you it's not going to happen. I hate it when people demand stuff like this. It's not very nice and very uncivil. [18:12:42] sali: this isn't the place for that and we know you're leilat, please raise this inquiry up with your local administrators [18:12:54] sali Nice try, you're not fooling us. [18:13:17] It violates content policy [18:13:38] sali: please stop [18:13:46] Allow fanbase page/qualities [18:13:48] Can someone please just kick this user out for disruptive behavior and refusal to drop the stick? [18:14:20] >Allow fanbase page/qualities this is against policies on FANDOM [18:14:29] not on Miraheze [18:14:40] anyway, wrong place [18:14:51] muted [18:15:13] Thanks. I've had just about enough of that user anyway. [18:27:57] Does Miraheze support anything like SSO? Where an account on another site can be used to auth on Miraheze and give you permissions on Miraheze (e.g. membership in a group on a specific wiki)? [18:28:52] We don't, no, as all accounts are global in nature here on Miraheze [18:29:01] Got it, thanks [18:38:05] Is there any reason bureaucrats can't remove other bureaucrats by default? Bureaucrats can change the setting, so it doesn't actually prevent you from doing anything. Is this just to prevent accidents? [18:38:39] I guess if you are the only bureaucrat and you remove yourself then Miraheze admins would need to step in, so maybe this is just to prevent you from shooting yourself in the foot? [18:38:41] It's to prevent takeovers. It's recommended a Steward removes the bureaucrat flag instead of another bureaucrat [18:39:07] But if a bureaucrat were to take over a wiki and demote everyone, a Steward can revert the change [18:39:16] Gotcha [18:39:37] But it's OK if we manage the bureaucrats on our site (adding and removing them as necessary) without asking a Miraheze Steward to step in, right? [18:41:00] adding them is fine, for removing them without a Steward's help, it's not recommended but it's not disallowed [18:41:04] cc dmehus: ^ [18:46:48] Is it OK to give the "ManageWiki" permission to the sysop (Administrators) group? I want sysops on my site to be able to do absolutely everything except add/remove members from the bureaucrats group. [18:48:04] Or will this be insecure in some way? Is there some way that having ManageWiki would let you control the bureaucrats group (e.g. by loading some extension)? [18:49:10] The issue is that the managewiki right grants you access to Special:ManageWiki/permissions which would allow sysops to name themselves above bureaucrats and demote them/assign extra rights to themselves [18:49:19] perhaps we should modularize ManageWiki permissions [18:49:22] @CosmicAlpha ^ [18:49:56] maybe make like a managewiki-extensions, managewiki-core, managewiki-namespaces, and managewiki-settings right [18:50:41] That makes sense. I think we'll still be OK because we have Miraheze Stewards to help us out [18:50:51] Agent: oh, not a horrible idea, though I'd still want to add a grant to the managewiki permission to keep current behaviour if we did that. [18:51:17] so if one of our sysops goes rogue and figures out how to add themselves to bureaucrats and does a takeover, we can still contact a Miraheze Steward [18:51:40] CosmicAlpha: yeah, that's what I was thinking too, to allow keep a managewiki right that grants you access to all of ManageWiki [18:51:53] perhaps a managewiki-settings group would be helpful though [18:52:03] to allow local sysops to control settings but not perms [19:05:09] If a sysop goes rogue and we have to ask a Miraheze Steward to step in, how long would it typically take to restore the site? (I understand that Miraheze is volunteer-run so you can't provide an SLA, but just asking in general what we might expect). Is it closer to 1 day, 1 week, several weeks? [19:05:56] I mean if a bureaucrat goes rogue [19:06:52] eh actually I decided this is very hypothetical and not worth time worrying about [19:08:08] @krrk: As soon as a Steward sees your request [19:08:25] so it can be as quick as a few minutes or up to a few days [19:08:36] OK, good to know, thanks [19:10:01] I think that's all the questions I have for now, thank you so much for your help! And thanks to Miraheze volunteers and donors who help keep the site going! [19:10:10] No problem :) [19:29:14] What are the most popular alternatives to Miraheze for MediaWiki hosting (whether free or paid)? The ones I'm aware of are Fandom and self-hosting on a VPS (e.g. Digital Ocean) where you install MediaWiki through cPanel [19:29:41] I'm 99.9% sure we're going to use Miraheze for hosting but I'm doing a presentation on our new wiki to the team and I want to do my homework by considering alternatives [19:33:02] https://www.mediawiki.org/wiki/Hosting_services [19:33:02] [url] Hosting services - MediaWiki | www.mediawiki.org [19:34:25] Thanks! Is there some way to get a sense of how popular each of these options is? [19:34:51] Apart from manually searching them up, I don't think so [20:59:43] long mh meeting :p [21:01:35] Agent: seen, what am I supposed to be doing here? [21:02:26] @krrk, do you require any assistance? [21:03:07] @dmehus nope, I was just asking in case I needed help in the future [21:03:55] Ah, just saw the question above; I would say ShoutWiki is the only known name that is general purpose, free and semi-updated, but as far as the Fandom/Miraheze/Shoutwiki trinary, it falls well into third place and everything else doesn't really compete for one reason or another [21:04:50] ShoutWiki still sees use, but loses points for version, tech staff (lack theirof) and feature set [21:06:50] Most of the options for 'hosting services' in the above links I would consider niche/problematic in one way or another, and it's a different kind of market when you consider something like a VPS. [21:07:40] @krrk, ah okay, that's cool. Yeah, basically what Agent said ^. It's strongly discouraged from giving bureaucrats the ability to remove other bureaucrats; `testwiki`, `metawiki`, and `allthetropeswiki`, and most Miraheze wikis follow this practice. Otherwise, we cannot guarantee you that your rights would be restored in the event of a "rogue takeover" of your wiki :) [21:09:32] Having a clearly defined set of policies for what 'should be' in the event you do change core settings (such as offering ManageWiki to sysops) would help you appeal to a higher power in the event you find a rogue takeover. The key in the event of a rogue takeover is being able to clearly define the rogues as such with a well entrenched policy on what should be that the Stewards can reference, otherwise they rely on global [21:09:32] convention. [21:09:41] @dmehus couldn't a rogue bureaucrat give themselves permission to remove other bureaucrats and then remove other bureaucrats? (Just asking because I'm curious and trying to improve my own understanding) [21:10:41] This is an excellent point, thanks. We will document the organization structure on our wiki. [21:10:56] Bureaucrats should be selected carefully for precisely the reason you mention. Though by global convention, if bureaucrats quite suddenly add themselves that ability and then perform a takeover, global convention can be used to say 'you shouldn't have done that in the first place' and better define the rogue action as such. Much more difficult if it's established that bureaucrats can manage each other in the first place. [21:12:35] ManageWiki is pretty much the god tool of a wiki and should be treated/distributed as such, but again having a solid image of what should be done will help when someone very dramatically changes the mold. [21:44:19] @krrk, yes, they could, and while Stewards could be asked to mediate and resolve that dispute, it may be very difficult, depending on the established procedures on the wiki and the discussions that established them. It's also very time consuming. Ideally, I'd love to the ability to remove other bureaucrats restricted to Stewards, but I don't think that's technically possible with ManageWiki/permissions [22:08:53] heh yeah, I'm never hosting a meeting on a Saturday again :P [22:10:27] Agent: the 15th is a Saturday, unless your rescheduling it? [22:10:45] CosmicAlpha: well that's unfortunate [22:10:59] Let's just leave it [22:11:31] The migration's date partially depended on the fact we have a Meeting the next day to gauge how it went [22:12:39] Yeah. True. But what happened in the meeting today? I was busy working on something I didn't really see much. [22:12:54] I'll just go read it I guess. [22:13:01] Agent, I think meetings are better on weekends :) [22:13:07] but we could move it to Sundays [22:13:08] CosmicAlpha: it was pretty uneventful, more than any other meeting before it [22:13:18] Agent, true, lol [22:13:20] The meeting before this meeting was that famous 5 hour one [22:13:25] it was like 90% on 502s/503s :P [22:13:27] this meeting was a very idle one [22:13:35] I wasn't really around too much for it too [22:14:18] dmehus: yeah [22:19:16] Agent: yeah, and I'll hopefully be here the entire time next time also, post-migration. Just read the entire meeting, not much really said I guess... but you did good explaining things.