Closed Bug 1332181 Opened 4 years ago Closed 3 years ago

Add ability to track and filter ongoing projects over time (deadlines, current status, priority)

Categories

(Webtools :: Pontoon, defect, P4)

defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: flod, Unassigned)

Details

While discussing our current issues within the PM group, we identified one main problem: we're missing a single point of reference to see which projects are ongoing, their size and deadlines, which locales are affected.

From an internal point of view that's important to evaluate incoming project requests, given that the same localizers are often spread across different products, e.g.:
* info per locale: "Can we ask more to German? Which projects are they already working on? How big are they? What's their priority?"
* info per product: "What's the status of project X?"

From an external point of view we've always received complaints about deadlines not being clearly available outside of webdashboard: when is this cycle ending? When is Beta going to be closed? etc. Sometimes that's important also from an internal point of view, think for example when covering for another person on a project you're not totally familiar with.

One important part is keeping track of the current status: it needs to be automatic. Given that we plan to enable Pontoon for all locales and projects, it seems natural to think about Pontoon to store all this information.

We identified two data objects.

Projects:
* General information about the project. Think of it like an extended version of the current project info in Pontoon.
* Useful links (stage server, repos)
* Testing instructions
* Point of contacts (teams, devs)

Tasks:
* A task is associated to a project
* Locales (critical/required, opt-in)
* l10n-driver in charge
* Priority
* Status (completion)
* Volume (number of words and strings)
* Tags (for filtering)
* Milestones (start, end, testing, etc.)

One project can have multiple tasks associated, e.g. one task per cycle for Firefox.

How to access this information?
* There should be public views with various filters: all projects vs ongoing (not completed), locales, tags, l10n-driver
* Display ongoing projects and deadline on the team page
* Possibility to access information about deadlines via calendar apps (think of it as Sched, without the painful UI…)


We don't think there's a tool able to satisfy this needs, especially considering the requirement to have almost-live updates on the status.
@PMs: does this cover well enough the discussion we had in MV?
Flags: needinfo?(pmo)
Flags: needinfo?(lebedel.delphine)
Flags: needinfo?(jbeatty)
I expect pontoon and elmo to be consumers of the configuration part of this. Stats would come from automation and be shown in pontelmo.

I guess I still have open questions on the difference between projects and tasks. Does a project have a status? Do we have deeper hierarchies (sub-thing for a firefox campaign on mozilla.org, being sub to fx-m.o, being sub to m.o) ?

Timelines come with the challenge that they love to be wrong. Even our official release calendars aren't always in sync. Which granularities do we need, or should we support? Days, in which timezone, hours, or weeks? Do we need to deal with "sometime next week"?
(In reply to Axel Hecht [:Pike] from comment #2)
> I guess I still have open questions on the difference between projects and
> tasks. Does a project have a status? Do we have deeper hierarchies
> (sub-thing for a firefox campaign on mozilla.org, being sub to fx-m.o, being
> sub to m.o) ?

Thanks for raising the point. I confess I'm a bit torn on project vs task, that's also the reason of the NI on the rest of the group.

We could live with just projects, e.g. create a project "Create ads for Firefox":
* It's tagged as "desktop", "android", and "ios" because it covers all 3 projects.
* It has a number of requested locales.
* It has clear milestones.
* It might have multiple l10n-drivers in charge.
* It has a status. Current completion when ongoing, completed, overdue if there are lingering requested locales.
* It doesn't really need depth, a flat structure would be enough (you filter by tag and locales).

In this scenario the problem are:
* How to deal with recurring tasks, e.g. cycles in products: do we create a "project" for "Firefox Desktop Aurora 53"? That might work.
* How to store shared information for this kind of projects (e.g. testing, priority, etc.). Do we introduce the concept of duplicating a project? Do we store it somewhere else?

> Timelines come with the challenge that they love to be wrong. Even our
> official release calendars aren't always in sync. Which granularities do we
> need, or should we support? Days, in which timezone, hours, or weeks? Do we
> need to deal with "sometime next week"?

I think we need timezone granularity, e.g. some tasks need to be done by "Friday morning PST" because there are people there in charge of the next steps (think screenshots hand-off). In other cases we might just make up one (e.g. Firefox cycles, we know the day, the time is pretty random).

One important detail that I forgot to mention: we need this system to figure out the workload, not just the current status of projects. In other words not just the pending work, but also what's already completed in a period.
I view tasks and projects as different. Projects have status based on tasks & timframe. I view tasks as being part of the execution phase of a project (translation, bilingual review, etc.).

Hope that helps
Flags: needinfo?(jbeatty)
Removing the ni off me as we agreed we needed to discuss this more during our upcoming meetings before we can agree and move forwards.
Flags: needinfo?(lebedel.delphine)
We've gathered more data and perspectives on this on a google doc: https://docs.google.com/document/d/1Qj5M6u2ZUat6558s6h9nTaIPpw48liCucSSw-Z0jds0/edit?pli=1
Marking as low priority until this gets more tangible.
Flags: needinfo?(pmo)
Priority: -- → P4
Please reopen or file a new bug when this gets more concrete.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.