Requests for Comment/Miraheze Data - a common structured data repository for Miraheze

From a conversation with an idea came out about providing Miraheze with a common repository of structured data. Much like Wikidata provides data to all the sites of the Wikimedia universe, Miraheze users could take advantage of having a commonly available place to share structured data. The reason supporting this proposal are similar to the ones behind the creation of Miraheze Commons. --Lucamauri (talk) 11:48, 24 January 2022 (UTC)
 * Initiators;
 * | Signature: --  Joseph  TB  CT  CA   14:31, 6 February 2022 (UTC)
 * | Signature: --Lucamauri (talk) 14:47, 6 February 2022 (UTC)

Disclaimer: What exactly are we averse to?
Although these proposals are made in good faith and for the betterment of the Miraheze universe, there are some things we don't plan of doing as these proposals are being made. We don't plan to; These proposals are solely for the betterment of the Miraheze universe. --  Joseph  TB  CT  CA   14:41, 6 February 2022 (UTC)
 * Overcomplicate our systems
 * Leave users out of the decision-making process
 * Add any more vandalism avenues

Previous discussions
A preliminary discussion was already started at T8630, where I was originally invited to open a RfC.

Proposal 1: Miraheze Data
The proposal calls for the installation of a Wikibase Repository that should be named, either  or. Meta Administrators as well as other volunteers (users) who are well knowledgeable in Wikibase should be administrators on the wiki, volunteers should be selected by most active users showing real interest in creating quality items. All administrators and property creators should take responsibilities of creating Properties, while, of course, Items should be editable by all the registered users, unless they're protected. Finally Administrators (This comprises of interested Meta admins and volunteers who becomes Sysop) should be in charge of adding new sites and enable SiteLinks to allow Direct Access feature. A clear process should be defined on how a wiki request access to the Data instance, so the administrator can add the site to the configuration. Documentation should be produced to explain wiki owners how to configure the Wikibase Client extension to access the Repository.


 * Note: This proposal is simply asking if you would want to see the Data wiki in existence, if you support/oppose/abstain the idea of having a structured data wiki. --Lucamauri (talk) 11:48, 24 January 2022 (UTC)

Support 1

 * 1)  as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
 * 2)  as one of the proposers --   Joseph  TB  CT  CA   14:55, 6 February 2022 (UTC)
 * 3)   Anpang 📨  02:02, 7 February 2022 (UTC)

Discussions/Comments 1

 * Sorry. I also saw that you can't vote now. This one was a note. Thanks. --YellowFrogger ( talk ) ( ✔ ) 17:00, 24 January 2022 (UTC)
 * Yeah, it isn't open for voting as more information needs to be added and that would be done any moment. --  Joseph  TB  CT  CA   21:17, 24 January 2022 (UTC)
 * 1) This seems like an intriguing proposal, but sort of structured data would Miraheze Data host? — Arcversin (talk) 17:11, 24 January 2022 (UTC)
 * Maybe I misunderstood the "would Miraheze Data host?" part, but it has nothing to do with that. One of the advantages of having a structured data repository is that we'll be able to organize wiki-text pages from all of the wikis that subscribe to it, allowing us to create machine-readable and machine-relatable pages for Internetbots like Googlebot and Bingbot to read. However, there are numerous more advantages. --  Joseph  TB  CT  CA   21:17, 24 January 2022 (UTC)
 * 1) Right off the bat I have a few concerns with this tbh; they range a few sectors. One is the fact that Commons for what it is, has very muted effectiveness. Not the best example. The second, the sheer variety of Miraheze data. Only certain niches of wikis would really benefit from this approach, and others might be better suited to developing their own Base. The third, the ambiguous and frankly problematic nature of ancillary wikis for Miraheze as it is; each one of them operates below where they should be in extension of the first point, and I would be uncomfortable in adding another before resolving the existing lineup in making a suitable baseline for the idea. Unfortunately I'm not sure there's much that a drafting stage for this proposal could do to remedy my thinking on this. --Raidarr (talk) 21:29, 24 January 2022 (UTC)
 * Your second concern is definitely gonna be addressed, maybe twas because users have refused to understand that this is still a draft and many areas haven't been addressed yet, so that is the reason you are raising the second concern. But let me throw a little light in that direction; It will be designed or organised in a way that no niche of wiki would be left behind, and for "and others might be better suited to developing their own Base." - This project would not by any chance be a must for wikis to subscribe to it, I mean, following our Wiki Statistics, approximately 97% of our over 5200 wikis do not have a Wikibase Repository, so you can see there are many wikis out there that might just be interested. Third concern; "Each one of them operatess operates below where they should be in extension of the first point" - I so much doubt if that is the case here, unless something has been tried out, I wonder how we'd be so sure that it's going to "operates below where" it "should be in extension of the first point". First concern; No matter how our Shared image repository looks like right now, it still function in a great way. This project is also going to enhance Miraheze Commons in such a way that we might have a way Images are also structured. For now, I think this would do. --   Joseph  TB  CT  CA   21:52, 24 January 2022 (UTC)
 * 1) .Do you plan to open this today, ? --YellowFrogger  ( talk ) ( ✔ ) 01:58, 5 February 2022 (UTC)
 * Probably by Monday or before. --  Joseph  TB  CT  CA   02:03, 5 February 2022 (UTC)
 * 1) You are an administrator of the wiki "Gratisdata. Will this also work the same way? --YellowFrogger  ( talk ) ( ✔ ) 14:59, 6 February 2022 (UTC)
 * That wiki works the same way wikidata work in terms of wikibase, but speaking of administration, it will/might vary from how this one might work. --  Joseph  TB  CT  CA   15:06, 6 February 2022 (UTC)

Proposal 1.1: Users' access and permissions
This proposal calls our attention to how users can access the content of the site. Using the same processes already in place in Meta (Nomination of RfP candidates, Requests for permission), A new group of such users should be elected.
 * Administrators and Property creators should be able to create and delete Properties
 * All the users with wiki connected to Miraheze Data as client wikis should be able to create Items;
 * All registered users on Miraheze should be able to add Statements to an item;
 * Any anonymous user should be able to browse. --  Joseph  TB  CT  CA   14:41, 6 February 2022 (UTC)

Support 1.1

 * 1)  as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
 * 2)  as one of the proposers --   Joseph  TB  CT  CA   14:55, 6 February 2022 (UTC)
 * 3)   Anpang 📨  02:02, 7 February 2022 (UTC)

Discussions/Comments 1.1

 * Please note that when creating a wiki, even directly via Special:CreateWiki, an initial "requester" must be specified, who will initially get bureaucrat access. As such, the proposal will need to account for that. — Arcversin (talk) 06:10, 7 February 2022 (UTC)
 * Arcversin, I would assume that Lucamauri, as the proposing user, would be named as initial, should this RfC pass. The Miraheze Data Wiki would then be a community wiki, and the wiki community could set its own procedures governing the addition and removal of local administrators and other users, as well as the addition of bureaucrats. Bureaucrat removals would still be handled by Stewards, and, as a community wiki, there could still be a proposal initiated on Meta Wiki governing the constitution of Miraheze Data Wiki, but preference would be for changes to be discussed locally where possible. Dmehus (talk) 06:15, 7 February 2022 (UTC)
 * this is actually a rather conflict-ridden and tenuous interpretation. Unfortunately, some initial discussion happened off-wiki across several of Miraheze's platforms. A lot of discussion occurred in T8630 specifically. dross  (t • c • g) 06:50, 7 February 2022 (UTC)
 * dross, I agree, that's fair. Perhaps in absence of that, this might be a case for the community to select a Steward as the initial bureaucrat, if this RfC passes, such that local policies can be established governing local bureaucrat appointment processes? Dmehus (talk) 06:57, 7 February 2022 (UTC)
 * That is perfectly okay if you ask me --  Joseph  TB  CT  CA   08:12, 7 February 2022 (UTC)

Proposal 2: Creating non-default usergroups
Assuming Proposal 1 passes in the first place, This proposal calls for the creation of user groups that are not installed by default (including but not limited to Property creators and Translation sysops user groups). Please share your view in the sub-sections of the proposal, below; --  Joseph  TB  CT  CA   14:41, 6 February 2022 (UTC)

Proposal 2.1: Creation of user group
This proposal is based on the fact that we will need translation administrators on the wiki because it will be a multi-language wiki, similar to Meta-Wiki, and thus we will need to use the Translation extension on the wiki. Wikibase is multilingual, though it does not require the translation extension, but we're talking about Wiki-text pages here, which can be translated using the Translation extension, such as pages in the Project, Template, and MediaWiki namespaces. --  Joseph  TB  CT  CA   14:41, 6 February 2022 (UTC)

Support 2.1

 * 1)  as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
 * 2)  as one of the proposers --   Joseph  TB  CT  CA   14:55, 6 February 2022 (UTC)
 * 3)   Anpang 📨  02:03, 7 February 2022 (UTC)

Proposal 2.2: Creation of user group
Because we'll be dealing with wikibase, we understand that not all users have a feasible understanding of handling wikibase properties and, as a result, may not understand what it takes to create, so we'll need to create a special group for users who aren't sysops but can handle property creation. This would aid in the proper administration of property creation. The name of this group should be known as. --  Joseph  TB  CT  CA   14:41, 6 February 2022 (UTC)

Support 2.2

 * 1)  as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
 * 2)  as one of the proposers --   Joseph  TB  CT  CA   14:55, 6 February 2022 (UTC)
 * 3)   Anpang 📨  02:04, 7 February 2022 (UTC)

Proposal 2.3: Creation of user group
Translation administrators user group would be needed since we'd be dealing with a multilingual wiki, the creation of this group would help specific users to translate wikitext pages into different languages. This would help welcome users of different languages to the wiki, especially users who doesn't understand English language. --  Joseph  TB  CT  CA   14:41, 6 February 2022 (UTC)

Support 2.3

 * 1)  as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
 * 2)  as one of the proposers --   Joseph  TB  CT  CA   14:55, 6 February 2022 (UTC)
 * 3)   Anpang 📨  02:04, 7 February 2022 (UTC)

Proposal 3: Election of core group members
This proposal calls for the election of users to be  on the Data wiki. Please share your view in the sub-sections of the proposal, below. --  Joseph  TB  CT  CA   14:41, 6 February 2022 (UTC)

Proposal 3.1: Electing Administrators
Administrators are more akin to housekeepers in that they are in charge of a wide range of tasks within a specific community. This proposal calls for the election of system operators (administrators) who will keep the community; this includes the Wikibase aspect and the Community aspect of the wiki, just like every other wiki needs administration. As previously proposed, Sysops should be able to create properties ( right) in addition to performing general housekeeping and cleaning. Meta sysops are already exempted, it now depends on if they're interested (Note: This exemption is for the meantime, that is, after the creation of the wiki, after the project begins proper, they (Meta admins) will no longer be exempted.) The proposers (Ugochimobi and Lucamauri) aren't exempted from this election. The same processes used in Local Meta Elections should be used to elect the admins (i.e. Nominations and Requests for permissions). --  Joseph  TB  CT  CA   14:41, 6 February 2022 (UTC)

Support 3.1

 * 1)  as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
 * 2)  as one of the proposers --   Joseph  TB  CT  CA   14:55, 6 February 2022 (UTC)

Abstain 3.1

 * 1)   Anpang 📨  02:04, 7 February 2022 (UTC)

Discussions/Comments 3.1
Honestly it might be good to implement a similar system on commons/dev/template wikis since it’s currently more at bureaucrat discretion. I do think that it might be good to allow existing admins on say commons wiki to be admins on this wiki without having to request permissions (just like what is being proposed with meta admins). I say this as a admin/bureaucrat on commons and template wiki who would love to help out with this wiki as well. MacFan4000 (Talk Contribs) 02:18, 7 February 2022 (UTC)
 * Yes, I agree and think there needs to be the same process for all our 'official' Miraheze wikis when it comes to administrator and bureaucrats. Reception123 (talk) ( C ) 06:15, 7 February 2022 (UTC)
 * There absolutely nothing wrong with that if you ask me, maybe this very proposal should be amended to this particular suggestion as it make sense to me, I don't know of --   Joseph  TB  CT  CA   08:14, 7 February 2022 (UTC)
 * I completely disagree with this. Instead I'd like to see stewards (or maybe sysadmins) the first bureaucrats of the wiki for time being. There are many inactive/rarely seen admins on meta, who I wouldn't like to be admins there too (given their inactive) and, personally, I wouldn't like the first admins of data wiki to be inactive, if it is created. --Magogre (talk) 08:22, 7 February 2022 (UTC)

Proposal 3.2: Electing Property Creators
Assuming Proposal 2.2 passes; Property creators are users who aren't system operators but are well knowledgeable in wikibase, these knowledge has to be demonstrated either on the Datawiki or a Miraheze wiki that uses Wikibase or even Wikidata. A simplier process can be used to elect Property creators. Proposed criteria are; Proven knowledgeability in wikibase, added a reasonable amount of statements to a particular item or property. Any Mirahezian can request for it or be nominated. --  Joseph  TB  CT  CA   14:41, 6 February 2022 (UTC)

Support 3.2

 * 1)  as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
 * 2)  as one of the proposers --   Joseph  TB  CT  CA   14:55, 6 February 2022 (UTC)

Proposal 3.3: Electing Translation Administrators
Assuming proposal 2.3 passes, this proposal calls for the election of translationadmins; User who will be able to translate wikitext pages. Per original creation proposal, This will help users who doesn't understand English language perfectly well to be able to interact with the wiki. --  Joseph  TB  CT  CA   14:41, 6 February 2022 (UTC)

Support 3.3

 * 1)  as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
 * 2)  as one of the proposers --   Joseph  TB  CT  CA   14:55, 6 February 2022 (UTC)