Actually, considering that other organizations (can) have also quarterly projects (IANM, WMDE already has) but not the same year, we definitely should stick into consistency, so it will be always obvious and sure which quarter is meant and not that 2016-Q4 will mean Apr-Jun for WMF and Oct-Dec for other groups...

+1.
Teams are encouraged to name quarters like "Apr-Jun-2016" instead of "2016-Q4".
There have been internal WMF discussions about this in the past about how impossible it is for "outsiders" to understand random Financial Years in random countries or companies, but with no clear outcome.

Any idea how to communicate this better, except for pointing out each time this is seen somewhere? :-/

In T134134#2255821, @Aklapper wrote:

Any idea how to communicate this better, except for pointing out each time this is seen somewhere? :-/

At least add a note to https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#New_projects

Maybe mass mail Project-Admins group?

Since some quarter projects already exist for a year ahead, I would strongly encourage to rename them as well. (This would be new task, mentioning it like a reminder.)

In T134134#2256359, @Danny_B wrote:

In T134134#2255821, @Aklapper wrote:

Any idea how to communicate this better, except for pointing out each time this is seen somewhere? :-/

At least add a note to https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#New_projects

Sounds good when it comes to project names.
However we also have workboard column names like that, I'm afraid...

Since some quarter projects already exist for a year ahead, I would strongly encourage to rename them as well. (This would be new task, mentioning it like a reminder.)

I'd also welcome a friendly request to its maintainers whenever we come across such names.

@Aklapper Let's turn this task to #rfc to find out the consensus on the form. Maybe we can add (orientational) poll too?

Q1 https://phabricator.wikimedia.org/project/query/i2w7YVJ1O66z/#R (2: releng, WMDE-tech-communication)
Q2 https://phabricator.wikimedia.org/project/query/IqTUlhMPiotW/#R (2: releng, WMDE-tech-communication)
Q3 https://phabricator.wikimedia.org/project/query/E6UBj.BxOWwO/#R (1: releng)
Q4 https://phabricator.wikimedia.org/project/query/HZpQQ14z7gq3/#R (4: collab, language-eng, releng, toollabs)

I don't think an RfC is needed. Easier to just:

• write to the teams,
• ask them to alter the primary titles (recommend that they either change to, or add, the "month-month" designation), and
• Note that it automatically adds the previous title as an "additional hashtag" so nobody will have to relearn muscle memory.

I'll talk to the collab team about it tomorrow, see if they raise any issues, and follow-up here.

What Quiddity says. I don't see a need for polls or RfCs.

<projectname>-2016-Jan-Mar or <projectname>-2016-01-03 ?
The former is "more legible", the latter is sortable...
Any other form?

@Quiddity Thanks for the research, but it's partial only.
There are other projects marking quarters various other ways (eg. Apr-Jun-2016 spotted recently), not only with ambiguous Q#.

I know I started this task only about Q# names, but for the sake of consistency, order and better searchability we should standardize the form completely.

Also there are months in project names as well, again, in various forms (Jan-2016, January-2016, 2016-January, 2016-Jan, maybe others...)

Considering that hashtags can supply linkable forms as well as suggest does, the project name probably does not have to stick to linkable form. So for the sake of sortability I would suggest the form <projectname> (2016/01-03) for quarters and <projectname> (2016/01) for months (and similar forms for other periods (<projectname> (2016/01-06) for half a year etc...)

I personally don't see a big enough need for consistency but I'm not against it either if people care. :)
(Using brackets in names would be the same format used for displaying milestone sub-projects, but not sure if anybody cares about differentiation.)
In general, it's better to avoid spaces in names due to having to replace them by _ when linking via a # prefix.

The collab team is fine with this change, but would like to keep "Q4" in the title, just for a really easy glance-check. I've changed Collab-Team-2016-Q4 to Collab-Team-2016-Apr-Jun-Q4

I don't think we should enforce too much consistency, but recommendations in the documentation would be helpful. I've tweaked https://www.mediawiki.org/w/index.php?title=Phabricator/Creating_and_renaming_projects&diff=2115047&oldid=2113840 - please add or edit, of course!

Brackets add twice as many characters as a dash. Slashes might make it harder to link to plaintext tag names (because of URL percentage encoding)(e.g. https://phabricator.wikimedia.org/tag/collab-team-2016-apr-jun-q4/). So I'd recommend against both those.

In T134134#2260016, @Aklapper wrote:

I personally don't see a big enough need for consistency but I'm not against it either if people care. :)

Consistency is a root of order...
I am ready to perform changes. My idea = my work... No need for anybody else to spend time on it...

(Using brackets in names would be the same format used for displaying milestone sub-projects, but not sure if anybody cares about differentiation.)

OK, suggest any other format?
Hmm, actually, shouldn't those be actually milestones anyway?

In general, it's better to avoid spaces in names due to having to replace them by _ when linking via a # prefix.

I've actually tested on labs, that suggest is quite helpful and automagically inserts proper form - no need to type it.

In T134134#2261270, @Quiddity wrote:

The collab team is fine with this change, but would like to keep "Q4" in the title, just for a really easy glance-check. I've changed Collab-Team-2016-Q4 to Collab-Team-2016-Apr-Jun-Q4

Great. Having a Q# mark at the end is totally OK. It does not break sortability.

I don't think we should enforce too much consistency, but recommendations in the documentation would be helpful. I've tweaked https://www.mediawiki.org/w/index.php?title=Phabricator/Creating_and_renaming_projects&diff=2115047&oldid=2113840 - please add or edit, of course!

Consistency is a root of order... Phabricator is unfortunately so messy ATM, thus not as usable as Bugzilla used to be... :-/
Thanks for the tweak!

Brackets add twice as many characters as a dash. Slashes might make it harder to link to plaintext tag names (because of URL percentage encoding)(e.g. https://phabricator.wikimedia.org/tag/collab-team-2016-apr-jun-q4/). So I'd recommend against both those.

Thanks for research. Please suggest any other reasonable form which would comply to needs described above.

Current format requests wrapup:

1. it should definitely be in descending order (= ymd) for the sake of sortability
2. it should use month numbers, not abbrevs for the sake of sortability
3. it may have other optional stuff appended after the timeframe description for the sake of backompat and quickcheck
4. it should not use slashes
5. it should not use brackets

If we should not use slashes (@Quiddity I'm a bit confused by your example, which does not explain me what's wrong on slashes...), we are probably stucked to dashes only, which makes numbers confusing, since 2016-01-03 (= Jan-Mar) could somebody interpret as January 3rd, 2016, therefore the actual result complying to all requests above seems to me to be: <projectname> 2016-01Jan-03Mar | <projectname> 2016-02Feb | <projectname> 2016-04Apr-06Jun-Q4 | <projectname> 2016-01Jan-06Jun etc...

In T134134#2261416, @Danny_B wrote:

1. it should definitely be in descending order (= ymd) for the sake of sortability

When and where exactly would you want to sort project names?

1. it should use month numbers, not abbrevs for the sake of sortability

"Apr" and "Jun" can be way clearer than "04" and "06", especially if you have more numbers in the project name.
Whatever-Apr-Jun-2016-Q4 looks like a very valid project name to me. :)

In T134134#2261416, @Danny_B wrote:

If we should not use slashes (@Quiddity I'm a bit confused by your example, which does not explain me what's wrong on slashes...), we are probably stucked to dashes only, which makes numbers confusing, since 2016-01-03 (= Jan-Mar) could somebody interpret as January 3rd, 2016, therefore the actual result complying to all requests above seems to me to be: <projectname> 2016-01Jan-03Mar | <projectname> 2016-02Feb | <projectname> 2016-04Apr-06Jun-Q4 | <projectname> 2016-01Jan-06Jun etc...

The problem with slashes is they can't be cleanly linked to.

• E.g. I've renamed the archived sprint board to "Collaboration-Team-Sprint-P-2015-02-11/q3/q3" and it autocompletes to the old name (hence the double/dangling "/q3"),
• and it cannot be linked to with {{ptag}} as used in mediawiki.org infoboxes, e.g. https://www.mediawiki.org/w/index.php?title=User:Quiddity_%28WMF%29/sandbox&oldid=2117254 links to https://phabricator.wikimedia.org/tag/collaboration-team-sprint-p-2015-02-11/q3/ which doesn't work
  • (It apparently autoconverts the slash into an underscore, per clicking on the tag name at https://phabricator.wikimedia.org/project/manage/1022/ which leads to https://phabricator.wikimedia.org/tag/collaboration-team-sprint-p-2015-02-11_q3/ )

So yes, dashes only.

Ah, renaming the collab board, broke the phlogiston reports. @JAufrecht let us know that these 2 fixes were needed:
https://github.com/wikimedia/phlogiston/commit/c4ea6956dbe71b67430989701742daf78ba25c69
https://github.com/wikimedia/phlogiston/commit/f8cb190bc48d8bd58e87ec3e27178528bd10dd76
Which reminds me to look at wikibugs... We'll probably need an update to:
https://git.wikimedia.org/blob/labs%2Ftools%2Fwikibugs2/HEAD/channels.yaml

Good things to keep in mind.
I've attempted a doc update, please fix/improve as needed. https://www.mediawiki.org/w/index.php?title=Phabricator/Creating_and_renaming_projects&diff=2120412&oldid=2115202
( @JAufrecht can you (or someone) add a suitable link, for the Phlogiston item there? ty!)

Where are we documenting the final recommendation for name usage? It's more general that Phabricator projects, but Phab project names are the first example of the slug usage case. In plain prose I think a good approach is FY2016 Q3 (Apr to Jun), but if the FY and CY don't match, it gets uglier: FY2017 Q1 (Jul to Sep '16), and neither is ideal for slugification: F2016-Q3-(Apr-to-Jun) is ugly.

@Quiddity, I updated the docs to mention Phlogiston. Thanks for the heads up.

In T134134#2268601, @JAufrecht wrote:

Where are we documenting the final reccomendation for name usage?

In the bulletpoints under "Come up with a good name:" at https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#New_projects

In plain prose I think a good approach is FY2016 Q3 (Apr to Jun), [...]

Andre and I mentioned brackets above...

Brackets add twice as many characters as a dash.

In T134134#2260016, @Aklapper wrote:

(Using brackets in names would be the same format used for displaying milestone sub-projects, but not sure if anybody cares about differentiation.)

The third problem with brackets is URL encoding, e.g. https://phabricator.wikimedia.org/tag/compact-personal-bar-%28beta%29/

All of those are minor, but worth considering. So brackets are probably weakly cautioned against, but not forbidden.

In T134134#2268601, @JAufrecht wrote:

but Phab project names are the first example of the slug usage case. In plain prose I think a good approach is FY2016 Q3 (Apr to Jun), but if the FY and CY don't match, it gets uglier: FY2017 Q1 (Jul to Sep '16), and neither is ideal for slugification: F2016-Q3-(Apr-to-Jun) is ugly.

If we don't see any issues with sub-projects using brackets for naming, we could go for SomeProject-Aug-Nov-2016 (FY2017-Q5). (I don't like spaces but things would get really ugly at some point otherwise.)
Generally wondering if teams should want to start setting up sub-projects (with their own boards) instead of separate Sprint project tags, though...

In T134134#2262760, @Aklapper wrote:

In T134134#2261416, @Danny_B wrote:

1. it should definitely be in descending order (= ymd) for the sake of sortability

When and where exactly would you want to sort project names?

https://phabricator.wikimedia.org/maniphest/report/project/
https://phabricator.wikimedia.org/project/query/all/
https://phabricator.wikimedia.org/maniphest/query/A7XO5nwArVoW/#R
etc...

1. it should use month numbers, not abbrevs for the sake of sortability

"Apr" and "Jun" can be way clearer than "04" and "06", especially if you have more numbers in the project name.
Whatever-Apr-Jun-2016-Q4 looks like a very valid project name to me. :)

That will break sortability.

Indeed... :-/ Which underlying use case would you like to cover by having sortability?

This came up again after some inconsistent and ambiguous wording in subproject naming.
If I had to choose && there's a need for quarters, formats like

• Team-Name-Q2-Oct-Dec-2016
• ProjectXY-Q2-2016-Oct-Dec
• Something2016-Oct-Dec-Q2

seem to be the least ambiguous formats and are all fine with me.

Less useful are FY201617-Q2-... and FY2016-17-Q2... but project descriptions can still explain which months in the Gregorian calendar that covers, and it's clear that Q2 does not refer to some single year in a Gregorian calendar (hence interested people would have to investigate).

Not acceptable is FY2016-Q2 style. It's ambiguous and misleading in many ways.

I am very much in support of standardizing this.

It would be nice to align it with whatever WMF communications is using for their standard (if they have one) so there is consistency across all the things.

Quoting relevant parts of WMF's internal Writing and Style Guide:

• Be clear when referring to the Foundation's fiscal year. Do not presume that readers will understand when you are referring to the fiscal year or just a period of time.
• Do not use forward slashes but hyphens and two digits for the second year (okay: 2008–09; wrong: 2008–2009 and 2008/09 and 2008/2009).

It doesn't say which type of hyphens and I prefer - to –. - is more ambiguous when concatenating stuff but - can be entered easily via most keyboards when searching within a page or for a project name.

Because our (WMF) fiscal year (FY) spans multiple calendar years, if you just say 2017 Q1, it's not clear whether you mean Jul-Sep 2016 or Jul-Sep 2017.

Teams within the foundation now are VERY quarter-oriented, so having the shorthand "Q3" is extremely helpful. Having only month names would be frustrating in many cases. Having both notations is most readable, but verbose.

If we have both, but only list the calendar year, then it would be very important to bind the months to the year tighter than the quarter to the year. For that reason, ProjectXY-Q2-2016-Oct-Dec seems ambiguous because it could either be "Q2 of the 2015-16 FY, which happens to be Oct-Dec", or "Q2 of whichever FY contains 2016-Oct and Dec".

Listing both months as numbers is problematic because "2016-01-03" looks like January 3, not January through March.

Thus, in the end, of all the proposals I have seen so far, I would favor:

• Something-2016-Oct-Dec-Q2

The Qx at the end will help staff, while the YYYY-Mmm-Mmm will help everyone else. The main drawbacks I can see are a) it's wordy, and b) it's not sortable. I don't see how we can achieve sortability, given all the other goals.

https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects currently says:

For time-limited projects, add dates or quarters. Do not only use ambiguous terms such as "Q3"; explain which months a quarter covers (cf. T134134).

Which is sufficient I'd say.

I'd like to clarify exactly what the current proposal is, since it's a link to a long list of terms. And because I think Kevin's last proposal is arguably better:

• Proposal 1, from T134134#2703477
  • Any project name in Phabricator which includes a date referencing WMF's fiscal calendar should be in the format #TOPIC-FY-2016-17-Q2
• Proposal 2, from T134134#2630930
  • Any project name in Phabricator which includes a date referencing WMF's fiscal calendar should be in the format: #TOPIC-2016-Oct-Dec-Q2

Between the two, I like #2 better, but this is a tough one because 1) we have two very different user groups, those who work constantly within the WMF fiscal quarter system, and the general public, and 2) we are trying to balance precision, conciseness, sortability, readability, and taste, and so there won't be a clear "right" choice.

Feel free and encouraged to agree on a proposal and to update the documentation accordingly. :)