User:Yair rand/Wishlist

From mediawiki.org
  • The community should have control of everything:
    • Scripts should be able to store arbitrary data, private and public, both associated with a user's account and not. Gadgets should be able to store preferences that don't disappear when a user switches computers. OnlineStatusBar and Drafts should be gadgetizable. Actually, pretty much everything should be gadgetizable. Keeping things in the hands of the community is a good thing, as is eliminating the need for communities to contact the devs. Live feeding data should also be allowed. Making a edit screen chatbox gadget is not going too far with this. Nor are javascript A/V Wikinews streams gadgets, "This user is actively editing:" boxes, or "Read this page later" user lists/buttons. Though really, I'm primarily thinking about Reference Tooltips preferences, watchlist gadget settings, and Wiktionary's various show/hide (currently cookie-based) settings.
    • All javascript should be community-editable. If the community wants to add something specifically to mediawiki.special.movePage.js, they should be able to do so. If they want to actually change some core js, they should be able to do that too. Same thing with all CSS.
    • All configuration changes should be handled by the community, including namespace changes and usergroups. It frequently takes weeks for bug reports on these things to be dealt with. Involving the devs for these things is unnecessary.
    • Post-wikitext-processing serverside scripts for modifying the HTML output. There shouldn't have to be enormous amount of DOM-modification on-load with JS. The community should be able to set regular expressions to run through the HTML, as well as more complex actions. On certain wikis, heavy DOM work is currently necessary, and it shouldn't be.
    • AbuseFilter should be capable of much more complex operations (think ClueBot NG), and be able to access essentially all public data. It should also be able to do any action any admin can do: protection, editing, etc., as well as notifying users. And it should be able sort changes into multiple tags in one filter (replacing WT "recent changes by language", for example.)
    • It should be possible to upload bots to a wiki. Users shouldn't have to run them on their own computers.
    • Dump analysis should be doable on-wiki. Downloading such enormous files should not be necessary. Nor should knowing whatever programming languages.
    • Real-time feeds of everything should be available. If one can find new stuff be repeatedly refreshing, they should be able to directly access a RT feed. (A few examples: RecentChanges, history pages, watchlists, contribs pages, categories, logs, whatlinkshere, TFAs and equivalents, relevant Wikidata changes...) Use Eventsource, WebSockets, etc.
    • Skins should be community editable, along with the configuration for the default skin. If not the entire skin, then as much as possible.
    • Templates should be virtually all-powerful. They should be able to access all public data (including histories), read the page the template is located on, modify their own arguments on save, perform all user actions (certain ones requiring a user with those rights to approve the template's use of those actions), store and read data, output raw HTML (again, subject to approval by those with user rights), and everything else feasible/not too dangerous. Most/all of this probably done through Lua.
    • ...
  • The wiki should include everything:
    • All coding, testing, reviewing, etc. should be done exclusively on the wiki. Code files should have simple edit buttons that allow users to edit with their normal account, without having to create special new accounts or install special software. There should be normal history buttons, talk pages, Show preview/Save buttons, watch buttons, and so on. Watchlists, recent changes, user talk pages, and contributions lists are all necessary. Users also shouldn't have to learn enormous piles of complicated rules to edit. Dealing with Git/Gerrit/SVN/(whatever the current thing is) is a nightmare. If users need to edit offline, have offline web apps, but don't leave the browser. Currently editing is unreasonably complicated, and things aren't going to get better until we have simple pages with normal edit buttons.
    • Mailing lists need to be integrated into the wiki. All messages should be readable, all lists watchlistable, all users able to comment, without giving out an email address. User contribs, recent changes, etc should include posts to mailing lists, whether posted from an email address or through the wiki. Using email addresses can be possible, but it shouldn't black out communications for those not using email addresses. Users should not be required to communicate through a parallel medium.
    • Bugzilla should be on-wiki. Wikimarkup, recent changes, user talk pages, regular SUL wiki accounts that don't require giving out email addresses to the whole world, watchlists, etc. You get the idea.
      • No Github bug tracking or coding either, please, in case that wasn't obvious.
    • IRC should be on-wiki. All wiki accounts should have associated identical IRC nicks. The channel should be accessible through the wiki itself.
    • No more behind-the-scenes communication. Seriously, keep things transparent. Communicating only through the wiki is the best way to do that.
    • ...
  • ...