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.
Let's discuss. Enabling the app is easy, but maintaining another Calendar is another story. We have https://www.mediawiki.org/wiki/Project:Calendar and https://www.mediawiki.org/wiki/Events already, which have already duplication. Before adding a third we need to consider what is the goal we should aim for.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T76094 Have tasks with due dates displayed on a calendar | ||
| Resolved | • mmodell | T466 Enable the Calendar app in Phabricator |
The benefit of phabricator's calendar is that it shows vacation status next to a person's name in convenient places like maniphest...This allows someone who is doing bug triage to easily see if a given developer is available to work on a task. So if someone is out on vacation or otherwise indisposed they won't get assigned with urgent tasks accidentally.
To respond to the description:
We have https://www.mediawiki.org/wiki/Project:Calendar and https://www.mediawiki.org/wiki/Events already, which have already duplication. Before adding a third we need to consider what is the goal we should aim for.
The Calendar app has zero overlap with those pages on MW. The Calendar app is for users to indicate their (lack of) availability. For instance, I just logged my 2 weeks of vacation in the upstream phab instance so they know I won't respond to any inquiries on my bugs during that time.
The Calendar app is optional (no one is forced to use it or even see it) and instead would be a nice for:
Yes, we have a google calendar at WMF, but that is:
Proposal:
:)
(T630: Enabling Herald is in its own top priority track)
Calendar seems to be enabled now. I think it would be useful to discuss it before, just like we are doing with other apps?
@mmodell just created E6: Phabricator Upgrade. Can we agree at least among ourselves on the current use of this application, please?
What more is there to discuss? I see nothing but support for this. There is zero maintenance cost, contrary to the description on this task. Also, it's getting a lot of love upstream and it looks like it's about ready for prime time.
Greg already made great points about why we should have it enabled. Additionally:
I want to test the app to see if it will be suitable for organizing swat deployments.
Nobody has offered any objections in several months, so what is the problem exactly?
Maybe the problem is only that Calendar was enabled and used silently before considering this task discussed and solved.
Some information about the new feature explaining its expected use and some documentation in Phabricator is also helpful. I myself don't know what are we supposed to do with it, so I guess most users are in the same situation.
@greg summed it up pretty well:
The Calendar app is optional (no one is forced to use it or even see it) and instead would be a nice for:
- Team managers with many team members to easily see what's the current bandwidth/likelihood of something moving forward
- (even more for) other teams/devs to know when someone who isn't on their team is available. eg: Jon Robson might not know that Antoine is taking vacation for a week in May and thus might get frustrated when he doesn't respond to inquiries thinking "ugh, Antoine is ignoring me!". If Antoine used the Calendar app that frustration would instead just be "Dang those Europeans and their holidays".
Yes, we have a google calendar at WMF, but that is:
- Only for WMF employees
- Who the heck looks at it? It's in a different browser tab (if at all) than where engineers do real work :)
When you set your status to away via an event then it takes that information into account in differential when adding a reviewer, and shows your status on your phabricator profile. Just a nice and convenient way to let people know you will be away.
It's potentially useful for everything we use google calendar for but I'm not going to advocate for that, YET... Once it gets a little more feature-complete then I would argue that we are obligated to give it a try, given the fact that it's a) free/open and b) already installed on our servers. Don't we have a policy of never using proprietary software when a reasonable alternative exists? I think this is pretty close to being a reasonable alternative. Enabling it is the only reasonable way to go.
Also, enabling the app is the best way to get some experience with it, then maybe we can document the use cases.
@mmodell: That sounds like the wrong order to me. Even if it was not the wrong order I'd still like to be aware (heads-up) that I need to spend time to (judge whether to) potentially document and communicate some newly enabled features. For an example of potential reactions when enabling new functionality, see the "Enable Conpherence for all users" task.
@Aklapper: Should I just enable it for teams that want to use it?
Honestly if people want to use something they should be able to, if it doesn't matter to them they shouldn't worry about it. We have a culture of fear around anything new that baffles me.
It might be useful to have a calendar for Pywikibot . As we're all volunteers, and no-one is a manager, sprints are not an option. Workboards have been useful to visualise what development is needed, but not (yet) useful for prioritising the work to be done.
However we could be better organised if we had one-day events lined up on a calendar for focused work in a subcomponent, or events for due-dates of important tasks that are time-sensitive due to pywikibot being used in real-world GLAM projects which have dead-lines.
Sort of; I've looked at it on a few other Phab sites where it is enabled. The lack of markup support in the app is astonishing (see https://secure.phabricator.com/T8032 and edit https://secure.phabricator.com/E990 to see just how bad the formatting is), so a Google calendar would be better. I am guessing that should be an easy fix. But being able to put simple note on a day in a calendar which looks like a calendar would be 'enough' to get the ball rolling.
What I am not sure about is whether it can do a 'team calendar' for a single project. I have only seen examples of 'My Calendar' and a calendar shared for everyone. Neither of those would be terribly useful IMO.
Based on the updates on https://secure.phabricator.com/T7950 , a 'team calendar' at present is events with a project invited, which will put the event on each persons calendar. That is good enough IMO. The lack of markup in the description is the most obvious pain-point, but comments support markup, so the event host can put an extended description using markup in the first comment after they create the event, and edit it in a moderated fashion.
Thank you, this was informative.
Seeing how this topic evolves, my personal opinion now is to enable Calendar after someone writes down a section in https://www.mediawiki.org/wiki/Phabricator/Help explaining what users can do with it. It is worth experimenting (our general situation with tech calendars is pretty bad anyways) and I don't see other blockers.
Can we at very least make it accessible to logged out users before we start using it officially?
We got Herald and we also got Spaces. Even Differential is enabled nowadays. Time to pursue Calendar?
I haven't followed the development upstream, and this is a pattern for anything that we haven't enabled here. I'm willing to learn. :)
In fact, looking at https://phabricator.wikimedia.org/calendar/ it is clear that Release-Engineering-Team is using it pretty extensively. Is there a way to get in (while this task is resolved for everybody)?
upstream development has been rapid, with most of the bugs now fixed. There is proper markup and project support now, and I expect the 'prototype' label to be removed soon.
@Qgil: There are currently a few bugs but the app is enabled so you should be able to use it.
It is a fact that the Calendar application has been enabled for some time now. Resolving this task.