The HockeyApp web console has a <select> list for the current status for an app for store builds. When the app is released on the App Store, we need to toggle the status accordingly.
Description
Description
Event Timeline
Comment Actions
@dr0ptp4kt can we make this a step on the release wiki page? That way we could just kill this here.
Comment Actions
It's already there, but I'd rather that we keep the card so that it is hard to forget this. I'm going to move this to Sprint 55.
Comment Actions
@dr0ptp4kt my feedback here is that we should make a process and stick to it.
I understand you want to make sure it gets done, but when we track things in 2 (public) places, they can get out of sync, it adds overhead, and it can be unclear to others what the actual process is ("where should I look for release tasks?"). Duplication means that we don't trust our release process and/or our tools.
We need to decide: Are we going to use a wiki to track release tasks or break them out into cards? We should do one, not both.
Lets figure this out and codify it in the release process. And trust that it works.
(As a side note, I keep a personal todo list if I want extra reminders or if I want to break down the task in a way that doesn't matter to anyone else. Its a good way to track important things that you don't want to forget)
cc @KLans_WMF
Comment Actions
Agreed.
I understand you want to make sure it gets done, but when we track things in 2 (public) places, they can get out of sync, it adds overhead, and it can be unclear to others what the actual process is ("where should I look for release tasks?"). Duplication means that we don't trust our release process and/or our tools.
In this regard, for this particular task, I trust Phabricator more. It's more visible. Would it make sense to remove this item from the MediaWiki.org page and track it solely in Phabricator?
We need to decide: Are we going to use a wiki to track release tasks or break them out into cards? We should do one, not both.
I would actually prefer to do the tasks in Phabricator. It does beg the question: which, if any, of the items on https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Releases should stay strictly on the release page on mediawiki.org? Maybe this is why there was a thought to have an actual release board that could give a glance all at once. I do feel like it's important to capture the stable channel release stuff in a column on the current sprint board as well just because missed opportunities there can cause pain for users and for ourselves.
Lets figure this out and codify it in the release process. And trust that it works.
Believe.
(As a side note, I keep a personal todo list if I want extra reminders or if I want to break down the task in a way that doesn't matter to anyone else. Its a good way to track important things that you don't want to forget)
As do I. GTD 4ever.
cc @KLans_WMF
Comment Actions
Yeah i don't mind one way or the other. If you like phab more for this that works for me - I feel like whatever works best for you since you are going to be working with it more than the other engineers. You could do it as a single task with checkboxes or multiple tasks. I would try to keep the overhead as low as possible, so would lean towards a single card on the sprint board (makes sense: to see when sprint 55 is released go to the sprint 55 board)
I don't want to put words in Bgerstle's mouth but I though maybe he did it as a wiki because it could become documentation for the future (when did that release go out?) that would be the only real plus I see on that side, but nothing that puts me over the edge. You could always pull up a phab board with the info as well.
Lets figure this out and codify it in the release process. And trust that it works.
Believe.
Lol
(As a side note, I keep a personal todo list if I want extra reminders or if I want to break down the task in a way that doesn't matter to anyone else. Its a good way to track important things that you don't want to forget)
As do I. GTD 4ever.
I am visualizing you making a gang sign.
cc @KLans_WMF
Comment Actions
Yeah i don't mind one way or the other. If you like phab more for this that works for me - I feel like whatever works best for you since you are going to be working with it more than the other engineers. You could do it as a single task with checkboxes or multiple tasks. I would try to keep the overhead as low as possible, so would lean towards a single card on the sprint board (makes sense: to see when sprint 55 is released go to the sprint 55 board)
I don't want to put words in Bgerstle's mouth but I though maybe he did it as a wiki because it could become documentation for the future (when did that release go out?) that would be the only real plus I see on that side, but nothing that puts me over the edge. You could always pull up a phab board with the info as well.
@bgerstle, heads up, planning to shift a number of items from the releases current state wiki page to a checklisted "release" type card that we have for every sprint. Some items are checklistable, others probably need to be filled in on the card (e.g., tag info). It will be easy enough to link from the existing Wiki to the current Phabricator card (and "archive" of old cards). If the destination Phabricator card itself has a checklist item to update the wiki, it will be hard to forget.
I am visualizing you making a gang sign.
On one hand a peace sign and the other a Vulcan salute.