User:John/Phabricator

A 'what they call' quick design plan!

Phabricator is going to become the new issue? planning? whatever you want to say? management system for Miraheze to unify the current split issue trackers at puppet, mw-config, CreateWiki GitHub reports and Request features. This is fair game as it's a really poor system. Anyway, here's my proposal on certain elements which by the time we launch it officially, will be the implementation plan thanks for open-wiki editing and collaboration!

Spaces
Spaces is the best possible way to enclose things entirely from the public engagement by putting them in a space (hence the name). At the moment I propose just one space:
 * Security
 * A space where all the private information can go and by default incoming emails from security@undefinedmiraheze.org will go.
 * As it's called security and will at the very least contain sensitive information or data about plausible security issues on our servers, I propose the space is only read-able by those who have a sufficient level of access (escalated sudo on a sever).

Status
The status of a task is how we really make progress. Therefore this should be simple at:
 * Open
 * Resolved
 * Invalid
 * Declined? Rejected? (something saying 'no, we won't')

Comment by southparkfan: the differences between Invalid and Declined/Rejected/Wontfix should be clearly defined!

Comment by User:NDKilla:
 * Invalid = Task does not follow any sort of format with no response from user and/or task is related to a bug that can't be reproduced or is proven to be not a bug (bug working as intended)
 * Declined = For whatever reason we decide not to take any action a request
 * Rejected = ^ Same thing but maybe more general for tasks, issues, project creation, etc? Ideas please
 * Wontfix = Legitimate bug report or related, but it is so miniscule and/or time to fix outweighs the cons of having the bug, so we make a reasonable decision to ignore the bug.

Comment by Reception123 I think that Declined and Rejected should be merged into one, as first of all they mean almost the same thing and second of all we don't really decline requests that much, so I think WontFix and Decline are enough.
 * I'm unsure where this confusion got introduced. There will be invalid then either declined or rejected. That's the discussion that shoild be here. Wontfix is useless as if you wontfix a bug, you're declining/rejecting it. Also wontfix looks rather ugly Imho. John (talk) 10:34, 13 April 2016 (UTC)

Priority
A basic design principle of priorities should exist like the status' above. There is no need to overcomplicated things so:
 * Unbreak Now!
 * High
 * Normal
 * Low

Simple and we'll clearly understand how things go.

Projects
Projects are how things are actually organised in Phabricator and in my opinion, the best thing about the move. As such I propose the following things with a basic description of them:
 * Operations (a general catch-all tag for things which affect the servers/infrastructure)
 * MediaWiki (a catch-all tag for MediaWiki things?)
 * MediaWiki-Extensions (a tag for new extension requests)
 * MediaWiki-Config (a tag for MediaWiki config changes/issues affecting the config of MediaWiki)
 * CreateWiki (a tag for CreateWiki and it's enclosed issues/tasks)
 * Puppet (a tag for things relating to puppet and things needing puppet changes)
 * Apache / NGINX? (a tag for things relating to Apache and NGINX work)
 * DNS (a tag for things affecting DNS/GDNSD or work for it)
 * Bacula (a tag for bacula related work)
 * Mail (a tag for things relating to mail, things that affect mail, postfix, dovecot etc.)
 * Monitoring (a tag for things relating to Ganglia and Icinga)
 * MariaDB / Database? (a tag for things relating to MariaDB and database related work)
 * Parsoid (a tag for parsoid work)
 * Redis (a tag for Redis work)
 * Piwik (or could we classify this as monitoring? monitoring analytical data?)
 * Varnish (a tag for Varnish related work)
 * SSL (a tag for SSL things like CSRs, certificates set ups, renewals etc.)