At least for Wikimedia, Files clearly wins over Pholio. While our design workflows are usually public, we have several private workflows where the most private part is a document attached (a file).

In T8434#118735, @Krenair wrote:

So... you propose that we simply kill the ability to add specific users to specific private tasks, is that right?

In general I also like the concept of "hard spaces", simpler to understand
and to protect.

I read the Nuance description, but it is still unclear to me what it does.

Oh, and about applications, Maniphest sure, followed by Files, then Mockups, perhaps. Paste... maybe.

The description posted above looks like a good first version.

This keeps being a problem for Wikimedia. Situations when the probability of clashes include someone sends an email to wikitech-l (more than 1000 subscribers), one team or more are working on something specific on a specific day, or, like this weekend, we organize a hackathon with 200 developers around.

I'm just concerned about the dates of first posts. I have a couple of conversations that happened in a single day, and now there is no way to tell when was that day.

Hm, I tested here and it worked well. Nevermind, then. I'm closing this task as Invalid and I will reopen if I can reproduce.

The original report seems to have been fixed at some point. See for instance T6502#110377 (which triggered an email notification as well). Resolved?

(posted just as memorabilia; no need to implement this) :)

Can a single user be awarded several badges?

In T4828#106461, @chad wrote:

I think this makes sense in Nuance, not Maniphest, from an upstream perspective.

Thank you for the quick reply. We'll see.

Yes, we give these instructions to our users. However, about 1 and 2, there just so much you can ask users to search in an instance approaching a 100k tasks, with an ok-ish search engine like Phabricator's. Even our expert users with a huge institutional memory miss a duplicate from time to time.

I recommend you to try this feature in Bugzilla. As far as I remember, the whole suggestion of potential duplicates is based on the title alone. The point is to save you writing a report that already exists, therefore making the check after the user has done the work would be... less good. (Probably better in terms of actual detection of duplicates, but probably resulting in less happy users thinking that you could have told them before writing the task).

Thank you, that was fast. We'll see.

I have posted the a request for paid prioritization in a short list of open tasks that I (and probably @greggrossmeier ) would be happy to ask budget for. Maybe we at Wikimedia can find some funds for small bites in this quarter, maybe we can go for larger bites for the next quarter / fiscal year starting in July. Maybe.

Would you be able to give a rough estimate for paid prioritization of this task?

Would you be able to give a rough estimate for paid prioritization of this task?

Would you be able to give a rough estimate for paid prioritization of this task?

Would you be able to give a rough estimate for paid prioritization of this task?

Would you be able to give a rough estimate for paid prioritization of this task? To simplify things, the implementation could basically clone the algorithm used by Bugzilla, since our users were quite happy with it.

Would you be able to give a rough estimate for paid prioritization of this task?

Would you be able to give a rough estimate for paid prioritization of this task?

In T7802#106309, @q wrote:

qgil : interesting read, but you can't really rely on mediawiki to host a would-be pseudo-manual.

In case it's useful, we have been creating Maniphest user documentation based on the questions we were getting in our project:

This new bug sounds like a different manifestation of the same problem: https://phabricator.wikimedia.org/T94155

I don't think the "without a description" part is correct. I think just creating a normal task with a normal description is enough to seed the problem. The custom field value is not set at creation, but only when someone edits the task (even without touching the custom field at all).

Ah, now I see that @jdloft here and Negative24 in Wikimedia might be the same user. :)

This might be the reason behind Phabricator should only notify changes to the "Security" field if it is indeed changed in Wikimedia Phabricator.

I brought this task again because we keep receiving feedback from our users against this approach, and I am genuinely interested in seeing whether you will get similar feedback channeled to you in your new role as Phacility hosting admins.

I'm looking forward to see whether the successful launch of Phacility and the new instances being created shed some light here. I still suspect most new users get confused about this defaut setting, mostly because I don't think it is found by default in any other popular service.

A hovercard for projects would be useful, but I agree with @chad that in fact the more important problem to solve might be in the typeahead

Yes, select a string to convert it in a clickable link, then click the "link" button.

I can reproduce this.

... and in any case there are many instances where we don't show users what they don't have permissions to do anything with. I think this approach is correct, since it shows simpler and cleaner UIs to the majority of new/plain users.

This report sounds like Wikimedia's Phabricator task search page doesn't scroll when mouse cursor over sidebar, which still can be reporoduced if you go to the sidebar of i.e. https://phabricator.wikimedia.org/maniphest/query/IF7FrspdWr3l/ , in the grey area below the menu.

I love them when I see them, but I don't need to click three times to get rid of their notifications.

Today Wikimedia Phabricator has been hit badly when we started importing the Phabricator repository (having forgotten about this problem). We stopped the import as soon as we saw our mailboxes flooded with notifications of commits and tasks marked as resolved.

In T7418#99197, @chad wrote:

M1421 for record has discussion on this feature.

Ok, for what is worth this is my own experience:

In T7410#99080, @epriestley wrote:

If you're seeing behavior contrary to that, it's a bug.

This problem is more relevant now that project tags and search suggestions point to workboards by default, instead of the default project page as before.

Hm, never mind. Now it works. I'm not sure what happened earlier today. Will pay more attention if I have problems again.

Is it just me, or the new workboards have brought a regression?

In T7266#96398, @qgil wrote:

I think that what actually confuses users is that the default option for general search after they register is not "Open tasks". Whenever they use the search field in the header, they get all those commits mixed with tasks, and they wonder why.

After a looong discussion, in Wikimedia we came up with a policy that avoids the use of spaces in project names. We use dashes instead. The reasons include the potential risk of breaking things by using spaces. Meanwhile, enough users would prefer to user the natural spaces instead of the techy dashes. If you have a recommendation about the use of spaces in project names, please share it.

In T4984#57937, @chad wrote:

I'd imagine we'd want to group them by Application.

Maniphest
W12 Unbreak Now Tasks
Display: ObjectList · Columns: 1, 2, 3
...

We have a similar request in Wikimedia that could be solved in the same way: Allow sorting by oldest and newest in Date Update/Created in search queries

I think that what actually confuses users is that the default option for general search after they register is not "Open tasks". Whenever they use the search field in the header, they get all those commits mixed with tasks, and they wonder why.