This is different from T12: (test) How do design attachments/assets work?, since an application can be enabled, but not shown on the default home page.
Current proposal:
Trusted User Tool deployment:
Day 1
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | • chasemp | T34 Configure Phabricator for our needs | |||
| Resolved | • chasemp | T193 Determine which applications should be enabled. | |||
| Resolved | Qgil | T26 Config: Disable Phriction wiki |
mattflaschen wrote on 2014-05-13 19:43:34 (UTC)
It looks like Ponder (Q&A) was disabled (it was on earlier). This could be useful, particularly if we use a license (T279) that matches the wiki (for easy copying back and forth). It could also be a place to send people who think they may have a bug, but it turns out just to be a question. This would be for questions about technical issues with the software (how to install/configure something, help with getting an extension working, question about a Lua script) etc, not wiki-specific questions (policies, which infobox to use, etc.).
There are potential reasons we might consider keeping it off. Some wikis (including MediaWiki.org and English Wikipedia) have help desks targeted for technical questions already, but I doubt all do.
This could potentially replace https://www.mediawiki.org/wiki/Project:Support_desk , or we could keep both.
swalling wrote on 2014-05-13 20:22:57 (UTC)
I've uninstalled the following applications:
demon wrote on 2014-05-13 23:37:06 (UTC)
I uninstalled xhprof, it's only meant to be used for development on Phabricator itself.
qgil wrote on 2014-05-13 23:38:38 (UTC)
About Day 1, I would enable only what falls within the scope of Day 1: task and bug management.
Since the documentation will live in https://www.mediawiki.org/wiki/Phabricator , it makes sense that support lives in MediaWiki as well. Otherwise the risk of having broken documentation in two places just increases.
qgil wrote on 2014-05-13 23:40:45 (UTC)
(Ooooh, no mid-air collision! I had started to type my reply before @demon posted his, yet both posts could just land at their right time) :)
mattflaschen wrote on 2014-06-02 19:20:03 (UTC)
Can we have Paste installed in the production version too?
I don't think we have any other Wikimedia site for this, and it's good for integrating Pastes into bug reports, etc (since you can embed or link them easily).
qgil wrote on 2014-06-02 22:06:21 (UTC)
A small but significant change caused by the Trusted User Tool project: we will launch a Phabricator instance in production only with Legalpad enabled.
The next steps will be geared toward Day 1 and will include Maniphest and the other apps required for bug / task management.
aklapper wrote on 2014-07-02 11:01:04 (UTC)
https://tools.wmflabs.org/paste/ (if that counts).
and it's good for integrating Pastes into bug reports, etc (since you can embed or link them easily).
I guess we could enable it.
Rush wrote on 2014-07-02 15:01:52 (UTC)
I would vote yes on paste since it's nice to keep all context for a ticket together and in prod
aklapper wrote on 2014-07-02 15:14:54 (UTC)
Alright, summarizing the current proposal:
If there's no other input or pros and cons, I'd say we're ready to go here?
Rush wrote on 2014-07-02 15:19:22 (UTC)
Mailing Lists - not to manage a list but to add them to a ticket as if it was a person for updates
Auth
Config
Rush wrote on 2014-07-02 15:26:06 (UTC)
oops also no legalpad here as for the moment they have their own space
https://legalpad.wikimedia.org (coming soon)
Rush wrote on 2014-09-06 14:41:12 (UTC)
no updates for a long time, closing this as it seems basically good
We can remove Files for now (see T373: get certificate for phab.wmfusercontent.org) and we can leave Legalpad.
There is no reason to keep a separate http://legalpad.phabricator.org and there is also the possibility to run the tech volunteer NDA process here, see https://wikitech.wikimedia.org/wiki/Talk:Volunteer_NDA (being experimented at phab-01).
We cannot --- "This application is required for Phabricator to operate, so all users must have access to it."
Rush wrote on 2014-07-02 15:19:22 (UTC)
Mailing Lists - not to manage a list but to add them to a ticket as if it was a person for updates
Auth
Config
I am going to add that to the initial description here. Mailing Lists would e.g. influence T453.
So if I get it right we need modules/phabricator/data/fixed_settings.yaml in operations/puppet.git to change https://phabricator.wikimedia.org/config/edit/phabricator.uninstalled-applications/ (by inverting the list given above)
My clueless attempt in https://gerrit.wikimedia.org/r/#/c/161624/ is awaiting review.
I'd like to request that the calendar app be enabled ... it's highly useful and I can see absolutely no drawback to enabling it.
Good idea... but might have more complexity behind, see T466: Enable the Calendar app in Phabricator and let's continue discussing the Calendar app there.
I think we should focus in closing tasks and avoid opening new discussions if they are not required for Day 1.
I have set the policies of all the apps to visible only to admins. This is an interim solution while Andre's patch is reviewed. Good enough to make this task not a blocker of T463 anymore.
As Chase pointed out in Gerrit my patch is the wrong approach, and we should disable apps that we want to disable in this specific instance via its web admin UI. @chasemp: Please correct me if I got you wrong.
Not quite, I need to go through the applications and verify their settings
and document the security stuff.