Proposal to invest in Phabricator Calendar

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal to invest in Phabricator Calendar

Quim Gil-2
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!

--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to invest in Phabricator Calendar

Legoktm
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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to invest in Phabricator Calendar

Ricordisamoa
In reply to this post by Quim Gil-2
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!
>


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to invest in Phabricator Calendar

Andre Klapper-2
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
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to invest in Phabricator Calendar

Faidon Liambotis
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to invest in Phabricator Calendar

Gergo Tisza
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 <[hidden email]>
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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to invest in Phabricator Calendar

Rob Lanphier-4
In reply to this post by 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to invest in Phabricator Calendar

Joel Aufrecht
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 <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to invest in Phabricator Calendar

Bartosz Dziewoński
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.

--
Bartosz Dziewoński

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to invest in Phabricator Calendar

Federico Leva (Nemo)
In reply to this post by Rob Lanphier-4
 > 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to invest in Phabricator Calendar

John Mark Vandenberg
On Tue, May 17, 2016 at 4:42 AM, Federico Leva (Nemo)
<[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to invest in Phabricator Calendar

Quim Gil-2
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 <[hidden email]>
wrote:

> On Tue, May 17, 2016 at 4:42 AM, Federico Leva (Nemo)
> <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to invest in Phabricator Calendar

Quim Gil-2
In reply to this post by Faidon Liambotis
Hi Faidon,

On Mon, May 16, 2016 at 1:53 PM, Faidon Liambotis <[hidden email]>
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).  :)

--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l