Annoyed by the difficulties of tracking events in the Wikimedia tech community? Or by the difficulties of announcing events in an effective way? Check this out:
Consolidate the many tech events calendars in Phabricator's calendar https://phabricator.wikimedia.org/T1035
The hypothesis is that it is worth improving the current situation with calendars in the Wikimedia tech community, and that Phabricator Calendar is the best starting point. If we get a system that works for Wikimedia Tech, I believe we can get a system that works for the rest of Wikimedia, probably with some extra steps.
The Technical Collaboration team has some budget that we could use to fund the Phabricator maintainers to prioritize some improvements in their Calendar. If you think this is a bad idea and/or you have a better one, please discuss in the task (preferred) or here. If you think this is a good idea, your reassuring feedback is welcome too. ;)
Thank you!
Hi,
On 05/13/2016 12:36 PM, Quim Gil wrote:
The Technical Collaboration team has some budget that we could use to fund the Phabricator maintainers to prioritize some improvements in their Calendar. If you think this is a bad idea and/or you have a better one, please discuss in the task (preferred) or here. If you think this is a good idea, your reassuring feedback is welcome too. ;)
If we're going to be investing money into improving Phabricator upstream (a great idea IMO), I think we should start with problem areas that affect a large number of users/developers. There's plenty of low-hanging fruit like non-drag-n-drop file uploads[1]. [2] was also mentioned on #wikimedia-tech a few days ago, or some of the UI/UX issues Nemo brought up after the last Phabricator upgrade[3].
[1] https://phabricator.wikimedia.org/T165#2289766 [2] https://secure.phabricator.com/T10691#167705 [3] https://lists.wikimedia.org/pipermail/wikitech-l/2016-May/085489.html
-- Legoktm
If we're going to be investing money into improving Phabricator upstream...
It's really good that we're having a healthy debate about the usability of Phabricator. I've enjoyed working with Phab a lot more than the tools that it has replaced, but it is by no means perfect. We have a role to play in helping Phab upstream make Phab more perfect.
That said, I think we should be careful with our assumptions about how much influence we can buy with the money we have. We need to be smart about how we spend it, but we also need to respect that we don't know what our role is in upstream's priority setting and roadmap. We shouldn't assume we're their most important customer.
Without identifying specific issues, let's assume that we have a feature list ordered like this: * Feature A * Feature B * Feature C ----- cut line for what we'd pay for ---- * Feature D * Feature E ----- cut line for features that we care about at all ---- * Feature F * Feature G
My (admittedly limited) understanding is that upstream is choosing between Feature C and Feature G as the next big thing they work on. If we chip in for Feature C, we could tip the balance and cause them to choose Feature C over Feature G.
I fear that a lot of the feedback seems to be "stop worrying about Feature C; Feature A is *way* more important". If upstream is making a C vs G decision, and we try distracting them with A, they may choose to ignore us and opt for Feature G. There is a significant opportunity cost in time and energy to spend influencing upstream to pay attention to Feature A.
So....getting out of the abstract and into the specific: is improving calendaring (T1035) important enough to invest a little money in, *considered independently* of the other features we may want? Is it above the "cut line for what we'd pay for" or is it less than that?
Rob
As I understand it, https://phabricator.wikimedia.org/tag/phabricator-upstream/ is supposed to represent the complete, current list of WMF needs for Phabricator. So any discussion in this list should, in order to be re-usable in the future and fully transparent, be reflected in that list via, at least, making changes to tasks and citing this discussion in the comments. So, are there specific Phab upgrade needs, or upgrade needs that have been expressed but not captured in a Phab task? If so, could their owners please add them to the board?
I have a few questions looking at that board that I'm happy to write up if someone can answer in this thread. Can the meaning of the columns be documented, e.g. here: https://phabricator.wikimedia.org/project/profile/6/ ? Looking at it, I have to wonder: - what is the difference is between Wikimedia Requests and Upstreamed? - If something has been Upstreamed, does that mean Phacility is going to work on it? Where would I go to learn the Phate of upstreamed requests? - How does something move from Backlog to Need Discussion to Ready to go to Upstreamed? - Are any of these lists prioritized?
Thanks,
Joel
*-- Joel Aufrecht* Team Practices Group Wikimedia Foundation
On Mon, May 16, 2016 at 9:46 AM, Rob Lanphier robla@wikimedia.org wrote:
If we're going to be investing money into improving Phabricator
upstream...
It's really good that we're having a healthy debate about the usability of Phabricator. I've enjoyed working with Phab a lot more than the tools that it has replaced, but it is by no means perfect. We have a role to play in helping Phab upstream make Phab more perfect.
That said, I think we should be careful with our assumptions about how much influence we can buy with the money we have. We need to be smart about how we spend it, but we also need to respect that we don't know what our role is in upstream's priority setting and roadmap. We shouldn't assume we're their most important customer.
Without identifying specific issues, let's assume that we have a feature list ordered like this:
- Feature A
- Feature B
- Feature C
----- cut line for what we'd pay for ----
- Feature D
- Feature E
----- cut line for features that we care about at all ----
- Feature F
- Feature G
My (admittedly limited) understanding is that upstream is choosing between Feature C and Feature G as the next big thing they work on. If we chip in for Feature C, we could tip the balance and cause them to choose Feature C over Feature G.
I fear that a lot of the feedback seems to be "stop worrying about Feature C; Feature A is *way* more important". If upstream is making a C vs G decision, and we try distracting them with A, they may choose to ignore us and opt for Feature G. There is a significant opportunity cost in time and energy to spend influencing upstream to pay attention to Feature A.
So....getting out of the abstract and into the specific: is improving calendaring (T1035) important enough to invest a little money in, *considered independently* of the other features we may want? Is it above the "cut line for what we'd pay for" or is it less than that?
Rob
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 2016-05-16 21:03, Joel Aufrecht wrote:
- what is the difference is between Wikimedia Requests and Upstreamed?
Presumably Upstreamed just means that a task about it has been filed at https://secure.phabricator.com/ and there's a link to it on our task.
That said, I think we should be careful with our assumptions about how much influence we can buy with the money we have.
Sure. Let's not make assumptions at all then: what makes someone think that calendar is amenable to WMF-mandated development? Already one year ago, I proposed that Phacility be hired to upstream our issues (and triage them upstream). https://lists.wikimedia.org/pipermail/teampractices/2015-March/000642.html
The reason is that so far I'm not aware of a single person in Wikimedia being able to talk with upstream (as opposed to talking past each other). https://phabricator.wikimedia.org/project/board/6/query/all/ seems to prove none exists, as the "Solved upstream" column lists a whopping 2 issues out of 500+ upstream issues.
Phacility could file the reports upstream in the way they prefer and optionally put a price tag on each request, without continuing to waste our reporters' time.
Nemo
On Tue, May 17, 2016 at 4:42 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
That said, I think we should be careful with our assumptions about how much influence we can buy with the money we have.
Sure. Let's not make assumptions at all then: what makes someone think that calendar is amenable to WMF-mandated development? Already one year ago, I proposed that Phacility be hired to upstream our issues (and triage them upstream). https://lists.wikimedia.org/pipermail/teampractices/2015-March/000642.html
The reason is that so far I'm not aware of a single person in Wikimedia being able to talk with upstream (as opposed to talking past each other). https://phabricator.wikimedia.org/project/board/6/query/all/ seems to prove none exists, as the "Solved upstream" column lists a whopping 2 issues out of 500+ upstream issues.
And of those two tasks, one is a regression and the other is an exception. i.e. not functional improvements.
I have added T109956 to that column, and would do more to help categorisation of solved tasks, but I note that "Solved upstream" is not explained at the documentation https://www.mediawiki.org/wiki/Phabricator/Code , so I wonder if I am doing something wrong.
It should be noted that we have successful built some local extensions/customisations, such as the Sprint. If we are having difficulty providing improvements to the core product, then funding incomplete extensions (like Calendar) is a good approach.
-- John Vandenberg
I wouldn't base any data analysis on the #Phabricator-Upstream workboard. Let's look at the tasks themselves.
https://phabricator.wikimedia.org/maniphest/query/Ou8pP.fE9ufA/#R shows 131 tasks with #Phabricator-Upstream tag and status Resolved. In almost every Phabricator update we are getting some fixes to bugs that were filed in Wikimedia Phabricator. If anything, I keep being impressed by the capacity of such small team to do so much work.
Rob is right pointing that our priorities will not be necessarily the Phabricator maintainers' priorities. Our experience discussing priorities with Phabricator maintainers is very good. By that I mean that they have a clear idea of their roadmap, what is aligned and what it isn't. Discussions about prioritization and funding have been pretty straightforward until now. Let's have our list defined, and then I'm sure Andre, Mikunda, Chad, Greg, and myself will be able to reach a good agreement with the Phabricator maintainers.
On Tue, May 17, 2016 at 2:07 AM, John Mark Vandenberg jayvdb@gmail.com wrote:
On Tue, May 17, 2016 at 4:42 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
That said, I think we should be careful with our assumptions about how much influence we can buy with the money we have.
Sure. Let's not make assumptions at all then: what makes someone think
that
calendar is amenable to WMF-mandated development? Already one year ago, I proposed that Phacility be hired to upstream our issues (and triage them upstream).
https://lists.wikimedia.org/pipermail/teampractices/2015-March/000642.html
The reason is that so far I'm not aware of a single person in Wikimedia being able to talk with upstream (as opposed to talking past each other). https://phabricator.wikimedia.org/project/board/6/query/all/ seems to
prove
none exists, as the "Solved upstream" column lists a whopping 2 issues
out
of 500+ upstream issues.
And of those two tasks, one is a regression and the other is an exception. i.e. not functional improvements.
I have added T109956 to that column, and would do more to help categorisation of solved tasks, but I note that "Solved upstream" is not explained at the documentation https://www.mediawiki.org/wiki/Phabricator/Code , so I wonder if I am doing something wrong.
It should be noted that we have successful built some local extensions/customisations, such as the Sprint. If we are having difficulty providing improvements to the core product, then funding incomplete extensions (like Calendar) is a good approach.
-- John Vandenberg
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
If we're going to be investing money into improving Phabricator upstream, I think we should start with making Differential usable (i.e. a suitable replacement for Gerrit)
Il 13/05/2016 21:36, Quim Gil ha scritto:
Annoyed by the difficulties of tracking events in the Wikimedia tech community? Or by the difficulties of announcing events in an effective way? Check this out:
Consolidate the many tech events calendars in Phabricator's calendar https://phabricator.wikimedia.org/T1035
The hypothesis is that it is worth improving the current situation with calendars in the Wikimedia tech community, and that Phabricator Calendar is the best starting point. If we get a system that works for Wikimedia Tech, I believe we can get a system that works for the rest of Wikimedia, probably with some extra steps.
The Technical Collaboration team has some budget that we could use to fund the Phabricator maintainers to prioritize some improvements in their Calendar. If you think this is a bad idea and/or you have a better one, please discuss in the task (preferred) or here. If you think this is a good idea, your reassuring feedback is welcome too. ;)
Thank you!
On Sat, 2016-05-14 at 20:51 +0200, Ricordisamoa wrote:
If we're going to be investing money into improving Phabricator upstream, I think we should start with making Differential usable (i.e. a suitable replacement for Gerrit)
If you have *specific* issues, please point them out by linking to tasks. "Usable" is too subjective to be a basis for discussions.
Thanks! andre
On Sun, May 15, 2016 at 10:59:40PM +0200, Andre Klapper wrote:
On Sat, 2016-05-14 at 20:51 +0200, Ricordisamoa wrote:
If we're going to be investing money into improving Phabricator upstream, I think we should start with making Differential usable (i.e. a suitable replacement for Gerrit)
If you have *specific* issues, please point them out by linking to tasks. "Usable" is too subjective to be a basis for discussions.
If we have spare budget for the FY, a good start, I think, would be (properly) implementing https://secure.phabricator.com/T5000, by implementing https://secure.phabricator.com/T8092 which in turn depends on https://secure.phabricator.com/T8093 and possibly depends on https://secure.phabricator.com/T4369 and https://secure.phabricator.com/T4245.
https://secure.phabricator.com/T10691 (depending on all of the above) could be potentially interesting for us too.
Faidon
It would also be nice to see spare funds spent on finishing the Bugzilla -> Phabricator conversion properly (it would build trust in our ability to pull of the other proposed transitions properly), see T687 (and other subtasks of T850). Although that would probably require local development, not Phacility sponsorship.
https://phabricator.wikimedia.org/T687 https://phabricator.wikimedia.org/T850
On Mon, May 16, 2016 at 1:53 PM, Faidon Liambotis faidon@wikimedia.org wrote:
On Sun, May 15, 2016 at 10:59:40PM +0200, Andre Klapper wrote:
On Sat, 2016-05-14 at 20:51 +0200, Ricordisamoa wrote:
If we're going to be investing money into improving Phabricator upstream, I think we should start with making Differential usable (i.e. a suitable replacement for Gerrit)
If you have *specific* issues, please point them out by linking to tasks. "Usable" is too subjective to be a basis for discussions.
If we have spare budget for the FY, a good start, I think, would be (properly) implementing https://secure.phabricator.com/T5000, by implementing https://secure.phabricator.com/T8092 which in turn depends on https://secure.phabricator.com/T8093 and possibly depends on https://secure.phabricator.com/T4369 and https://secure.phabricator.com/T4245.
https://secure.phabricator.com/T10691 (depending on all of the above) could be potentially interesting for us too.
Faidon
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Faidon,
On Mon, May 16, 2016 at 1:53 PM, Faidon Liambotis faidon@wikimedia.org wrote:
If we have spare budget for the FY, a good start, I think, would be (properly) implementing https://secure.phabricator.com/T5000, by
I have reflected your request at https://phabricator.wikimedia.org/T135327#2304387
implementing https://secure.phabricator.com/T8092 which in turn depends on https://secure.phabricator.com/T8093 and possibly depends on https://secure.phabricator.com/T4369 and https://secure.phabricator.com/T4245.
Copied to https://phabricator.wikimedia.org/T127#2304394 fwiw.
https://secure.phabricator.com/T10691 (depending on all of the above)
could be potentially interesting for us too.
Do we have a related task in Wikimedia Phabricator?
In any case, please reflect your proposals at https://phabricator.wikimedia.org/T135327 directly, because this is where we are looking at for candidates. (I moved Faidon's feedback to Phabricator because he is a nice person and because I probably owe him a KEO beer or two). :)
wikitech-l@lists.wikimedia.org