Talk:Principles

PHP

I considered making it "mainly in PHP" because that's the starting point but we have an increasing amount of JavaScript, 5 % in core and over 20 in extensions according to ohloh.[1] (Not to mention all the JS served via gadgets and so on; if only they weren't such a mess, they'd be worth mentioning on the same level as extension for their important as regards customisation... after all, the WebAPI is good enough, but the internal PHP API for extensions is a disaster.) --Nemo 12:03, 29 July 2013 (UTC)

I don't think that the implementation language belongs in principles at all. We should continue to use the best tool for each job, whether that is PHP, JS (Parsoid, Mathoid, PDF renderer, VE, Rashomon), C (caches, Apache, MySQL), Lua (templates) or Java (search, Cassandra, Hadoop). By number of requests served pure C would win by far. -- Gabriel Wicke (GWicke) (talk) 03:58, 15 January 2014 (UTC)

Well, caches are not MediaWiki and MediaWiki was originally called "the PHP script", so there was some truth in it. :) --Nemo 07:05, 15 January 2014 (UTC)

I think PHP is often used as a proxy for a stable platform that's available basically everywhere. It doesn't really matter where you choose to host, they'll have PHP available. There's a de facto principle that we don't introduce hard dependencies on things that are hard to install, and many things have pure PHP implementations. I think this level of portability is important, and makes MediaWiki a lot more accessible for e.g. students running it on their raspberry pi's or other low end hardware. I'd rather see that as a principle (portable/runs nearly everywhere) rather than a specific language implementation. Legoktm (talk) 18:51, 20 November 2018 (UTC)

Overriding principles

20.15 < sumanah> In http://aosabook.org/en/mailman.html there's an interesting bit about what their overriding concerns are: [...]
20.16 < brion> ooh that’s not a bad idea
20.16 < brion> ‘never lose data destructively’ (unless you really need to)
20.16 < brion> ‘audit logs for everything’
20.16 < brion> ‘make it easy to use’

Open data

I'm wondering if we should state or imply somewhere that MediaWiki is so much open data ante litteram. Few or no other wiki engines have such wide import/export capabilities and web APIs. --Nemo 08:45, 9 January 2017 (UTC)

Yes :) Legoktm (talk) 18:52, 20 November 2018 (UTC)

Developed openly

I'm not sure if it fits in this document (which seems to describe what MediaWiki is, rather than how it is made), but I think we should document somewhere that MediaWiki is developed openly. Our discussions take place on public mailing lists, public tickets, etc. (keeping in mind Technical_Collaboration_Guidance/Principles#Private_Planning). Even if issues are security related, we practice full disclosure and make sure that once the vulnerability has been fixed, the details surrounding it are made public. And more Wikimedia related, we have wikitech:Incident documentation, which is also shared openly.

So does this idea belong as part of Principles? Maybe we need a separate page explaining the concept (does one exist alraedy?) that Principles can link to. Legoktm (talk) 18:32, 20 November 2018 (UTC)

Maybe we can borrow a bit from #3 of the Debian Social Contract. Legoktm (talk) 20:44, 23 January 2019 (UTC)

Shared hosting

Do we still think "shared hosting" belongs on an equal level with the other principles here? Maybe it's time to generalize it as "deployable on widely-available low-cost cloud platforms" or something like that... cscott (talk) 22:33, 26 March 2020 (UTC)

More specifics on point #1, "wiki software"

Please see this essay for an in-depth exploration of point #1, specifically the bullet point "fully transparent and observable." -Pete Forsyth (talk) 20:00, 27 May 2020 (UTC)