Talk:Everything is a wiki page

From mediawiki.org
Latest comment: 6 years ago by Elitre (WMF) in topic Tracking

What about private data?[edit]

Watchlist items and echo notifications and thanks are required to be private. Wiki pages are public by nature. How does one model these as a wiki page?

Also what about things that we may want to be private and then turn to public e.g. drafts (there are good reasons a draft may want to start off as private)

Thus do you mean to say everything public is a wiki page or do you have hopes the wikipage model can evolve?

How would a privately modelled watchlist work at scale which has to join with recent changes? If this was modelled as a page wouldn't it also have to be modelled in the database in practice? --Jdlrobson (talk) 16:00, 2 March 2016 (UTC)Reply[reply]

Principles says MediaWiki is "fully transparent and observable", which runs counter to having private things. In one of the recent RfC meetings, I believe someone said that if watchlists were designed today, they'd be public. And we already have infrastructure for public watchlists thanks to Special:RecentChangesLinked.
I don't really understand your point about thanks and echo notifications though, the page says "every publicly-visible content", which notifications and thanks are not. Notifications are actually derivatives of what can be found in the revision/page/logging tables. Legoktm (talk) 18:12, 2 March 2016 (UTC)Reply[reply]

My message was based on reading an older version I read last night. I see it's been updated since then to be clearer

> "Principles says MediaWiki is "fully transparent and observable", which runs counter to having private things. " Sure, but, I still think there is use in private and it needs to be considered (and was of the original motivations in Gather to use database storage along with the need to do highly performant SQL queries).

Many of my emails to public mailing lists and my phabricator comments sit in a private draft mode for days until I am ready to post them so I can make sure I get my point across effectively. I'm aware of many editors who also draft wikipedia articles for new page creation in Google Docs before posting them. It would be good if MediaWiki thinks about this.

I remember a discussion about users wanting to make watchlists of certain users known to cause vandalism. Would these be valuable if public and editable by those users causing the vandalism? I don't think so.

It would be useful to consider if it would be useful for the wiki page had a limited concept of private in some form. The fact is we do have a notion of private in the wiki as it stands.

Jdlrobson (talk) 18:31, 2 March 2016 (UTC)Reply[reply]

FWIW Renaming this to "Everything that is public is a wiki page" might be a good idea. Jdlrobson (talk) 18:33, 2 March 2016 (UTC)Reply[reply]

see also Jdlrobson (talk) 15:51, 4 March 2016 (UTC)Reply[reply]

Wiki pages aren't everything[edit]

If this was modelled as a page wouldn't it also have to be modelled in the database in practice? --Jdlrobson

I think this is an important point as well. For "advanced" features (e.g. Wikidata) having content available in a structured and efficiently queryable database storage format is often necessary. I don't think this has to be seen as contradictory however. There is no technical limitation preventing the canonical representation of content from being modeled as a wiki page using ContentHandler and that data also being mirrored into database tables with an appropriate schema on page save. The largest complication of such a model would come from attempting bi-directional synchronization between the wiki page and the alternate database representation. For most (all?) use-cases this additional complication should be avoided. --BDavis (WMF) (talk) 16:25, 2 March 2016 (UTC)Reply[reply]

ContentHandler has functionality to update "secondary" database tables, which are derived data from what is in the page. Any form of bi-directional synchronization would have to edit the page since what is stored in the text table is the canonical representation of the page. Legoktm (talk) 18:14, 2 March 2016 (UTC)Reply[reply]
Is it actually a requirement to have a full textual representation of the content (as opposed to, say, only storing in text a reference to rows in some other table)? The documentation is not very clear on that issue. --Tgr (WMF) (talk) 19:01, 3 March 2016 (UTC)Reply[reply]

Quick thoughts[edit]

Thank you for starting this page! A couple of quick thoughts:

  • The Translate extension is pretty horribly rough to use. Its markup is impenetrable to most users, even long-time users. I'm not sure it's a great example to cite, especially as the extension does not take advantage of ContentHandler.
  • Pages in MediaWiki have incredibly coarse read and write restrictions currently.
    • It's difficult to lock out a particular editor from editing a page, so we have blanket protections instead (full protection, semi-protection).
    • It's basically impossible to remove read rights from a specific page, unless it's a Special page.

This isn't a counter-argument to "everything is a wiki page," but similar to other commenters above, I think we should identify the deficiencies of wiki pages. Doing so will allow us to improve wiki pages and obviate the need for others to implement their own thing rather than using wiki pages. --MZMcBride (talk) 18:49, 2 March 2016 (UTC)Reply[reply]

I'd agree that Translate (And maybe LiquidThreads) aren't exactly the best examples of everything being a wikipage being good. Although I do agree with this page in principle. Bawolff (talk) 17:48, 3 March 2016 (UTC)Reply[reply]
Examples are just what quickly came to my mind in 5 minutes. I intentionally included examples created both before and after ContentHandler, but the specific choice of examples can be changed (please edit!). Nemo 18:00, 3 March 2016 (UTC)Reply[reply]

Tracking[edit]

Is there a tracking bug for things that should be wiki pages? --Tgr (WMF) (talk) 19:23, 3 March 2016 (UTC)Reply[reply]

User:Nemo bis, ^^^. --Elitre (WMF) (talk) 10:12, 9 March 2016 (UTC)Reply[reply]