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

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

A good-faith idea, with an articulated rationale and analysis; however, there is no consensus to create a centralized Miraheze Wikidata depository, with cogent and logical arguments presented on both sides; however, given that most users presenting arguments from the opposing and neutral sides, consensus seems to be trending towards being against. It is, however, stalled. It should be noted that wikis can, always, still create their own Wikidata repository wikis, and many wikis do. As Proposal 1 does not pass, the other proposals cannot pass with no centralized repository wiki having passed. The proponents are nonetheless thanked for initiating this detailed RfC, rather than simply requesting a wiki. Dmehus (talk) 00:15, 13 February 2022 (UTC)

---

From a conversation with @Ugochimobi: 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;

Ugochimobi | Signature: --  Joseph  TB  CT  CA  14:31, 6 February 2022 (UTC)

Lucamauri | 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;

• Overcomplicate our systems
• Leave users out of the decision-making process
• Add any more vandalism avenues

These proposals are solely for the betterment of the Miraheze universe. --  Joseph  TB  CT  CA  14:41, 6 February 2022 (UTC)

Previous discussions

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

Quick SWOT Analysis

	Helpful	Harmful
Internal	Strengths: Single, centrally managed installation of Wikibase will be able to support any number of wikis within the farm. Structured data are becoming more and more important in knowledge base-like systems as wikis	Weaknesses: There is little expertise in WikiBase installation and maintenance in general Choosing between standalone and containerized Wikibase installation is the first choice standalone is easier, but SPARQL and QS might prove impossible to implement Wiki configuration needs to be customized both in the Repo and Client instances when a wiki needs to use the system Administration of the site might prove complicated (for instance handling properties definition and creation) Specific demands from vastly different wikis might lead to proliferation of properties and data useful only in specific cases
External	Opportunities: Attract more users providing a ready-to-use Wikibase installation As Wikidata is not accessible outside Wikimedia farm, public Wikibase instance on Miraheze could be interesting for the general public Organisation of wiki-text pages from all wikis that subscribe to it, allowing us to create machine-readable and machine-relatable pages for Internetbots like Googlebot and Bingbot to read It will allow; Users to link content across Miraheze wikis, readers to delve deeper into our knowledge ecosystem, and contributors to spread information across wikis and beyond in a structured manner.	Threats: Federation might never work in a proper way Wikidata might one day be opened to the general public, possibly rendering this repository useless

Proposal 1: Miraheze Data

The proposal calls for the installation of a Wikibase Repository that should be named, either data.miraheze.org or base.miraheze.org. 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.  Support as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
2.  Support as one of the proposers --  Joseph  TB  CT  CA  14:55, 6 February 2022 (UTC)
3.  Support  Anpang📨  02:02, 7 February 2022 (UTC)
4.  Support If nothing else, this would provide an easily accessible place for wikis to centrally store interlanguage links without having to set up their own wikibase instance. — Arcversin (talk) 15:46, 7 February 2022 (UTC)

Abstain 1

1.  Abstain After reading the supports as well as the opposes it is difficult for me to form an opinion on this matter. I am concerned that this wiki will not use its full potential and will be rather inactive like the other similar wikis but I am not sure enough about that to oppose it yet. I may change this vote in light of new comments. --DeeM28 (talk) 05:28, 8 February 2022 (UTC)

Oppose 1

1.  Oppose for several issues with this. 1, referring to Miraheze Commons merely reminds me that Commons goes used by a very limited set of users and has become administratively decayed, that is, it has an abundance of unused user rights, it has minimal activity in general, and it like other ancillary wikis of this nature are in need of structural cleanup, and I am not comfortable supporting this until the very principle of ancillary wikis created by RfC or to supplement Meta are addressed. 2, structured data per the preceding point has little use in a centralized location for the vast majority of wikis requested on the platform. The few exceptions I know of are probably best served utilizing their own repositories until there is progress on 1. 3, regarding 'external' points, I'm concerned of the implications of general public use given the limited resources of the platform as it is, and given the individual or closely interlinked nature of wikis on Miraheze my concern falls to point 2 as far as how broadly this will actually come in useful. In sum I find this proposal unnecessary, useful only to a very niche audience, and uncompelling in its reasons for support as well as actually more compelling in its own provided reasons for why there might be issues. There is insufficient organization and 'meta awareness' for this to be more than a red herring to other platform improvements, in my view. --Raidarr (talk) 10:23, 7 February 2022 (UTC)
2. Per Raidarr's point 1. This is highly likely to get abandoned like the other related Miraheze wikis have. I don't feel comfortable enough to support these proposals for a plenty of reasons which I'd rather not bring up. Strong oppose, sorry. --Magogre (talk) 02:38, 8 February 2022 (UTC)
3.  Oppose I have really been trying to be convinced that there is a marked need or desire, or even a place for this project in the wider Miraheze community. Unfortunately, I see no way to affirm that position. As many others have expressed, the vast majority of projects do not benefit directly from the implementation of structured data, and those projects which do benefit would likely benefit more from structured data specific to their project. By all means, I would encourage the creation of a Wikibase project if it is something you are passionate about. You could even catalog all public Miraheze project data as structured data in such a project, and I'm sure many other users would join in as well. I simply do not believe that the "official" or "Miraheze" implementation is viable. I see no issue with this fundamental concept as a personal project, though. dross (t • c • g) 05:43, 9 February 2022 (UTC)

Discussions/Comments 1

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)

   @YellowFrogger: 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)

2. @Lucamauri: This seems like an intriguing proposal, but sort of structured data would Miraheze Data host? — Arcversin (talk) 17:11, 24 January 2022 (UTC)

   @Arcversin: 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)

3.  Comment: 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)

   My apologies for not replying to this sooner. Frankly, I missed it. But in continuity of my vote, I'm not sure that the second is sufficiently addressed, though that's more my thing in the same vein as strongly advising against mass imports of wikipedia templates; sure, they're fancy, but they're all a bit much for what the overwhelming majority of cases I've observed actually, or ever need. Most of the wikis do not have a repository because a) admittedly they're just not aware, but I would argue b) because it looks like a fair amount of work for nebulous benefit and then c) because it is indeed overkill for probably well over 90% of them to estimate conservatively. The current repository functions in a great way for a tiny volume of scenarios, and until the formula is addressed I'm personally not comfortable in voting otherwise. But of course I must defer to the procedural outcome here. --Raidarr (talk) 20:32, 7 February 2022 (UTC)

4.  Comment: .Do you plan to open this today, @Ugochimobi:? --YellowFrogger (talk) (✔) 01:58, 5 February 2022 (UTC)

   @YellowFrogger: Probably by Monday or before. --  Joseph  TB  CT  CA  02:03, 5 February 2022 (UTC)

5.  Comment: You are an administrator of the wiki "Gratisdata. Will this also work the same way? --YellowFrogger (talk) (✔) 14:59, 6 February 2022 (UTC)

   @YellowFrogger: 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.  Support as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
2.  Support as one of the proposers --  Joseph  TB  CT  CA  14:55, 6 February 2022 (UTC)
3.  Strong support  Anpang📨  02:02, 7 February 2022 (UTC)

Discussions/Comments 1.1

• @Ugochimobi: @Lucamauri: @Anpang: 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 bureaucrat, 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)

  @Dmehus: 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 phab: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)

  @Dmehus: 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 translationadmin 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.  Support as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
2.  Support as one of the proposers --  Joseph  TB  CT  CA  14:55, 6 February 2022 (UTC)
3.  Support  Anpang📨  02:03, 7 February 2022 (UTC)

Proposal 2.2: Creation of propertycreator 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 wikibase-properties, 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 propertycreators. --  Joseph  TB  CT  CA  14:41, 6 February 2022 (UTC)

Support 2.2

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

Proposal 2.3: Creation of translationadmin 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.  Support as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
2.  Support as one of the proposers --  Joseph  TB  CT  CA  14:55, 6 February 2022 (UTC)
3.  Support  Anpang📨  02:04, 7 February 2022 (UTC)

Proposal 3: Election of core group members

This proposal calls for the election of users to be sysops, crats, property creators and translation administrators 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 (property-create 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.  Support as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
2.  Support as one of the proposers --  Joseph  TB  CT  CA  14:55, 6 February 2022 (UTC)
3.  Support MacFan4000 ^{(Talk Contribs)} 21:58, 7 February 2022 (UTC)

Abstain 3.1

1.  Abstain  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)

@MacFan4000 and Reception123: 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 @Lucamauri: --  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 inactivity) 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)

I don’t feel like it should be that restrictive. Commons did start out with sysadmins getting rights (that’s how I got rights) but I think the currents admins there are not limited to sysadmins, and bureaucrats have only granted rights to users who they trust not to misuse them. And also re meta admins, they would only get rights if they requested it I believe. They wouldn’t just get rights by default. Also there is a local rfc regarding admin inactivity. MacFan4000 ^{(Talk Contribs)} 12:47, 7 February 2022 (UTC)

I am not trying to make it restrictive, I am just trying to avoid what has happened to commons and other related wikis. Complete inactive admins! And the whole maintenance performed by a single translation admin and steward sometimes. If they are not using their tools on Commons (or even meta in some cases), what assures you that they'll use them on Data wiki, if the RfC passes. --Magogre (talk) 14:32, 7 February 2022 (UTC)

Those wikis aren't super active anyway, an so there isn't ever much for admins to do. If somebody needs an admin to do something, they can just ask us on IRC or similar.We're around, there just isn't a whole lot to do, since the wikis aren't very active. MacFan4000 ^{(Talk Contribs)} 16:49, 7 February 2022 (UTC)

commons:Category:Deleteme exists for a reason on commons which admins should regularly check. I won't always inform admins about every single deletion request I'll make, they'll need to check wiki regularly. And what do you mean there is not much to do, there are a lot of files which are either uploaded using license laundering techniques or missing essential information. A lot number of files are deleted by Agent Isai periodically, which are either spam, fail license review or miss essential information. --Magogre (talk) 17:25, 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.  Support as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
2.  Support 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.  Support as one of the proposers. --Lucamauri (talk) 14:52, 6 February 2022 (UTC)
2.  Support as one of the proposers --  Joseph  TB  CT  CA  14:55, 6 February 2022 (UTC)

Discussions/Comments 3.3

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section