Thing's I'd like to see in extensions and shipped with the default
install (maybe not each item in it's own, a lot of these could be
grouped)
Maintenance reports
* Broken redirects
* Dead-end pages
* Double redirects
* Long pages
* Oldest pages
* Orphaned pages
* Pages with the fewest revisions
* Pages without language links
* Protected pages
* Protected titles
* Short pages
* Uncategorized categories
* Uncategorized files
* Uncategorized pages
* Uncategorized templates
* Unused categories
* Unused files
* Unused templates
* Unwatched pages
* Wanted categories
* Wanted files
* Wanted pages
* Wanted templates
Recent changes and logs
* Gallery of new files
* My watchlist
* New pages
* Recent changes
* Related changes
Media reports and uploads
* File path
* MIME search
* Search for duplicate files
Wiki data and tools
* Popular pages
* Statistics (just the presentation, not the backend system)
* System messages
Redirecting special pages
* External links
* Random page
* Random redirect
High use pages
* Most linked-to categories
* Most linked-to files
* Most linked-to pages
* Most linked-to templates
* Pages with the most categories
* Pages with the most revisions
Page tools
* Compare pages
* Export pages (not the api, which can do this)
* Global file usage
*Global template usage
* Import pages (not the api, which can do this)
Other special pages
* Book sources
* Watchlist system
I'm not saying these aren't useful, in fact I bet a few would be used
everywhere. So ship them in related-groups as extensions that come
default-on. It really should be up to system admins if they want to
keep them. It would also mean that for almost any given special page
you always know which folder to go into. Why maintain two different
places for special pages and their translations? Some of these I'd
also love to see alternatives to, I'm sure a lot can be done GUI wise
and if you want to use an alternative an admin might not want to keep
the old one, and present a cohesive package to her users.
Chad also joked about making the parser an extension, and I'm no
expert on it but given how much trouble WYSIWYG editors are having
with our wiki syntax, I wouldn't mind being able to say "yeah sure
this is a wiki from scratch, I'll accept the CKeditor syntax instead"
and have one that works great (and has show source!) Especially if I
could mark all current pages as using Parser A, and new pages or edits
get converted to Parser B.
In the end I think what decorifing brings to the table is:
* Freedom of choice through modular programming, creating an extremely
strong plugin/extension system
* Atomic entities that are easier to test independent of each other
and translate
* Able to transition from testing an alternative to making it the
default seamless and almost risk-free. Think about it, if the default
is an extension that is hooked in, it's trivial to ship an alternative
"up and comer" alongside it for people to try, and if it becomes more
attractive, you can just flip the switch and make it the new default.
People who prefer the old can go back to it.
You maintain the idea of shipping a "complete" package to your users
by bundling extensions (as Brion mentioned) and you foster and promote
a very healthy contributing community by making the barrier to entry
low and the rewards higher.
I'm very new to this community, and Brion seemed to indicate that this
was already the plan, but that wasn't the story I was getting
elsewhere. Nevertheless I apologise if I'm talking a little too loudly
to the choir. I hope I can get up to speed on what's going on very
quickly, by exploring the lists and documentation (you've got a
decade's worth! please be patient), voicing my thoughts and questions.