Talk:Phabricator/Archive 1

. ''

Documenting our usage of Phabricator
In relation to the Phabricator RfC and http://fab.wmflabs.org, we are starting to see useful questions and answers about the way we use the Phabricator tools. Let's update this outdated page documenting here the good practices. The discussion about Wikimedia Phabricator yes/no still must go to Requests for comment/Phabricator‎.--Qgil (talk) 15:36, 24 April 2014 (UTC)

Test instance or not
«!NOTICE! This is a test install, be prepared to lose data or manually migrate to the future real instance at a later date. This instance is not meant for long term use.» but then it's said to be ok for posting important/production information. Who's right? Please update the notice if things changed. --Nemo 07:10, 9 August 2014 (UTC)
 * It can be used for "real" data by those willing to be guinea pigs, however everybody should be aware that some data still could get lost (though daily backups are in place, so in worst case you lose 24h). And it's correct that the specific Labs test instance is not meant for long term use - the production instance will be. --AKlapper (WMF) (talk) 11:46, 9 August 2014 (UTC)
 * I think the warning is fine to make sure that testers know that they are testers. However, "or manually migrate to the future real instance at a later date" could be removed because it is inaccurate. We are planning to migrate the valid projects to the production instance.--Qgil (talk) 21:46, 9 August 2014 (UTC)

fab.wmflabs.org down for migration
Summary: fab.wmflabs.org will be taken down this Monday 8th 18:00UTC. Locally save tasks or workboards that you might rely on for the week. Verify your email address in fab.wmflabs.org if it's not already. The intention is for the Phabricator production instance to be available by Sept 12th.

The Phabricator instance on fab.wmflabs.org has been used over the last few months for both real and test data. On Mon, Sept 8th 2014 18:00UTC this instance will be made unavailable to migrate content to the upcoming production instance on phabricator.wikimedia.org. The Labs instance will not come back online in the same form, if at all.

We take the Labs instance down because we cannot make the Labs instance read-only while dumping its data. Neither can we easily display a banner on all pages warning you to not make any changes which would get lost anyway.

Tickets from the following projects are marked for migration:


 * Analytics-EEVS
 * Architecture
 * bugzilla-migration
 * Chemical_Markup_for_Wikimedia_Commons
 * Code_review_in_Phabricator
 * Community-Engagement
 * dev.wikimedia.org
 * googlelogin
 * Growth
 * Human_Resources
 * Language_Engineering
 * logstash
 * phabricator
 * phabricator-request-project
 * Release_Engineering
 * rt-migration
 * Triagers
 * Trusted_User_Tool
 * UI_Standardization
 * UploadWizard_Refactoring
 * Upstreaming_to_Phabricator.org
 * Wiki-Release-Team
 * Wikimedia_Phabricator_Day_1
 * wikimedia_phabricator_maintenance
 * wikimedia_phabricator_rfc

Some metadata for tasks associated with the above should be populated in the new production system -- if the account used in fab.wmflabs.org has a verified email that is also verified in the production instance. If you are using an email but have not verified it to the Labs instance you can go here: http://fab.wmflabs.org/settings/panel/email/ and choose "verify". An email will be sent with a link.

If you do not have a verified email address yet, or for some reason cannot verify an email with the Labs instance the relevant content (tickets, comments) will still be migrated. However, it will not be associated automatically with any new account in the production instance.

For questions catch us (chasemp and andre__) on Freenode IRC or drop into the channel.

Thanks,

Phabricator Team


 * and horizontally by placing it inside
 * -- FriedhelmW (talk) 10:56, 11 April 2015 (UTC)
 * -- FriedhelmW (talk) 10:56, 11 April 2015 (UTC)

Massive google+ spamming
JFTR, if it is not on commons for some reason it is by definition spam. Of course it can be also spam if it's on commons, but the deletion procedure would be straight forward in this case. Please do not spam for Google wannabe-services in any form, no matter if it is YouTube-spam, Maps-spam, Google+-spam, or spam for 1001 former now dead services killed by Google (Usenet archive, reader, buzz, maps API v2, whatever.) –Be..anyone (talk) 03:54, 11 April 2015 (UTC)
 * What is the relation of your comment to Wikimedia Phabricator? Context welcome. --AKlapper (WMF) (talk) 10:23, 11 April 2015 (UTC)
 * G+ isn't . Somehow a link to the good /versus Bugzilla subpage vanished leaving only the wrt bandwidth huge G+ hangout. I've inserted the /versus Bugzilla blurb again, it could be removed next year when really nobody recalls what bugzilla was. –Be..anyone (talk) 07:16, 13 April 2015 (UTC)
 * Where is this hangout that are you abbreviating about? --Tim&#160;Landscheidt 07:36, 13 April 2015 (UTC)
 * If you refer to the "The Very Basics of Phabricator" link (I can only guess and I still don't know what that "massive spamming" refers to), I replaced the Hangout link by a Youtube link in the article now and anybody is welcome to convert that Youtube video and put it on Commons. --AKlapper (WMF) (talk) 09:50, 13 April 2015 (UTC)
 * Thanks, CC BY-SA is better, even if YouTube manages to link it to their own CC BY page which links CC BY 3.0. Unfortunately 300 MB MP4 + 38 MB M4A download + convert + upload about the same size to commons would eat too much of my 5 GB per month plan. Commons always wants the best, no matter how big it is, up to 976 MB. –Be..anyone (talk) 15:32, 13 April 2015 (UTC)

No idea how to report a bug
I'm just a simple bloke. Having clicked a bunch of incomprehensible stuff and read screeds of text and seen several screens that made me want to scream I have no idea how to report a bug. --Dweller (talk) 12:29, 29 June 2015 (UTC)


 * Is how to report a bug not clear enough? --121.219.253.36 12:36, 29 June 2015 (UTC)
 * Looks better than anything I've seen so far, although still scary. Shame it's not linked in Phabricator. --Dweller (talk) 12:40, 29 June 2015 (UTC)
 * Thanks for pointing out this problem! I hope this edit made it clearer. --AKlapper (WMF) (talk) 13:17, 29 June 2015 (UTC)

EzPlan, EU "Active" and other extensions for mediawiki useful to integrate?
Extension:EzPlan and the PM formats supported by the EU "Active" project are of later origin than the deprecated CC:Teamspace  and Extension:Semantic_Project_Management mentioned in the Project_management_tools page. That page should be updated.

More importantly, has anyone looked at situations when either of these currently-maintained extensions should be used, or other extensions like Semantic Bundle provides, when people want to co-operate in a mediawiki to help a development process along? For instance, to detail a spec or to describe a use case, or other things that are better done in mediawiki than in Phabricator?

The project of implementing Phabricator should include clearly identifying what mediawiki should be used for, what extensions are helpful to use it for that purpose, and how it should be integrated into Phabricator. A few incredibly useful extensions would likely result from just studying this.

The combined knowledge of the user community is all tied up in mediawiki skills and format, but only a tiny number of those will ever use Phabricator, so the workload is cut drastically if we can maximize the usefulness of mediawiki itself in the Wikimedia development process, in the long term.

Some kind of roadmap for integration of mediawiki and Phabricator would be ideal. But for now, just a review of what extensions will help users to cut the workload of the Phabricator users (i.e. developers), by feeding in data in a form that Phabricator itself can make immediate use of...


 * Hi, to discuss content of Project management tools it's probably more effective to directly post on the related Discussion/talk page (the content of that page is nowadays most for historical reasons). For the reasons why Phabricator was chosen over other options (such as MediaWiki itself), see the links in the "Past steps" section on Phabricator. Regarding "integration of MediaWiki and Phabricator", specific problems that you see and would like to solve would be interesting, as "integration" can mean a lot of things. :) --AKlapper (WMF) (talk) 20:27, 30 June 2015 (UTC)

Am I the only one...
...increasingly frustrated by the lack of a "thanks" system in Phab? Too many times I want to thank people for a comment or an action, and awarding tokens is just too generic (and confusing FWIW). --Elitre (WMF) (talk) 14:15, 11 March 2016 (UTC)
 * I do, but probably not as often as you since I am not very active on Phabricator — Ltrlg (talk), 20:02, 11 March 2016 (UTC)
 * This is funny, -- I was thinking exactly the same thing yesterday, because I wanted to thank you. :) -Pete F (talk) 19:45, 15 March 2016 (UTC)

Inclusion or deletion in Phabricator?
All, I am an occasional user of Phabricator, and have found it a very useful tool. Sometimes the bugs I enter are addressed; other times they are not. When they are not, sometimes I get information about why not, and other times I don't. As a wiki user, I am used to working in an environment like this; once in a while I am frustrated when I enter a bug and hear nothing back, but it's not really a big deal -- if anything, that's useful information, because it means if I want to get action taken, there is still work to be done in finding the right people and/or describing the issue better.

The one thing that is always frustrating to me is when my bugs are closed with a reason like "that project isn't managed on Phabricator." That doesn't help me, if it's unaccompanied by a pretty specific suggestion about how to contact the people who can help -- and it sets me back a little, because now even if I do find those people, Phabricator has been identified as an inappropriate resource for tracking it and moving it forward. It also suggests that it's incumbent on me, an end-user, to determine what project is appropriate before I even decide whether or not Phabricator is the right venue. Perhaps "Fundraising Sprint Beastie Boys" is the right project for my bug? I have no idea. It looks to me like there are, maybe, hundreds of active projects, and I often haven't the slightest idea what a project might be named.

I recently found that has written on this topic, which is great -- for the first time, I can start to get a handle on the thinking around this. Their essay on the topic argues the opposite, but is clearly presented: User:Krenair/Phabricator projects. We discussed it a bit on their user talk page. (Have also discussed a bit with .) But ultimately, I'm not sure of the status of that essay -- does it reflect an actual policy? Or is there widespread disagreement about how liberally Phabricator should be used? I would like to hear more about this -- and about what to do when I find a software-related problem in the Wikimedia world, but don't know what project it might or might not be connected to, or whether or not that project is managed on Phabricator (or might be in the future). -Pete F (talk) 20:59, 15 March 2016 (UTC)
 * I am glad this is being discussed.


 * "I am frustrated when I enter a bug and hear nothing back, but it's not really a big deal -- if anything, that's useful information, because it means if I want to get action taken, there is still work to be done in" - 'hear nothing back' as in no one even touches your task, or no one comments/fixes it? Bugs in some projects get at least a basic read by other people (and often some priority set or categorised into a column). Also, I don't think this is always acceptable to most users. We should avoid leaving users in a situation where no one will even read their task - while we have stuff like tasks with no projects mostly covered, what happens if you make a task that's only got a tag project listed (like tracking or something)? It's highly possible no one will find it for a long time (some of these could be very high priority, others less so).


 * Tasks being closed because "that project isn't managed on Phabricator." is something that I suspect should be happening more than it currently does. Yes, you should theoretically be expected to figure out which projects to add (at the moment, if you add none, it's likely that someone will add projects if they are in Phabricator, or close it if not), and right now I think that can be a challenge for new users. Since I know that you're here from a gadgets task, I should add that with these, the reporter should be considered be lucky to get much more contact info than "the administrators of your wiki". Wikis do not all have a standardised place for that, it should not be the closer's task to figure out if such a place actually exists or not (they might not have access to the wiki, they might not be able to speak the language, etc.), you may end up contacting an admin directly (e.g. via user talk or email). The gadgets thing specifically is interesting actually - why do some people appear treat it so differently from modules/templates?


 * My essay is by no means a policy (I don't think I'm a senior enough MW developer to walk around declaring such things policy just like that, I've only been around for like 4 years, and even if I was I probably wouldn't just do it), but it shows some of the ideas that I consider and apply when closing tasks (task closing is very rarely something determined by policy anyway). A developer closing your task does not necessarily mean it's completely hopeless - e.g. they can be reopened by users pointing out the problem is actually a miscommunication/misunderstanding, other developers disagreeing fundamentally, etc (and as you saw, even if it is the wrong forum, some people may still actually be able to help you, the problem is that there's no guarantee and we should try to set reasonable expectations to reporters around this). It's not clear to me at the moment how many people agree with the essay, I haven't got a lot of feedback (maybe if I linked to it every time the subject came up, it would get more attention?)


 * I kind of wonder if some much more comprehensive guidelines for task creation based on subject (e.g. say "for editor-controlled article content (e.g. wiki articles themselves, individual wiki gadgets, etc.), phabricator is the wrong place." and "before reporting a bug with mobile software, remember to specify whether it's for an app (specify android or ios) or the mobile web"), with some explanation that only tasks intended for projects which are actually tracking issues in Phabricator should go to Phabricator, would be a good idea. I wouldn't go too far with it - i.e. we probably shouldn't (to use an example from my work with the foundation) expect non-VE-developers to identify which parts of VE are generic and which are MediaWiki-specific, and know to add the VisualEditor-MediaWiki project. But still we run the risk of making it look too complicated. -- Krenair (talk &bull; contribs) 04:03, 16 March 2016 (UTC)
 * Okay, I was resisting this temptation, but it turns out to be very relevant here: w:en:WP:DEVBEANS from June 2006 (almost a decade ago), especially the last section or two. -- Krenair (talk &bull; contribs) 04:10, 16 March 2016 (UTC)
 * When closing a task as "not being tracked in Wikimedia Phabricator" people should point out where the person who already graciously spent their spare time to report the problem should bring it up instead. Regarding the bigger topic what to (not) track in Wikimedia Phabricator and why, discussion in T85433 is related. --AKlapper (WMF) (talk) 14:03, 18 March 2016 (UTC)