...and the simple task count ones were just as good

Some teams are confident that they can evenly size tasks

You can set a global default in Edit Task → Configure Form → Edit Form Configuration → Change Default Values → Type Some Number → Save Defaults.

Cool. I'll merge this into T5000, then -- beyond the mechanics discussed there, that's broadly the "provide smoother onboarding workflows so you can use Phabricator more gradually" task.

You can click the buildable to get a positive summary (see B12021, e.g.):

See also T10691.

I can't reproduce this. Here's what I did. I created this Herald rule:

It's also fine to not fix this, or just fix some of it -- the affected tasks shouldn't do anything bad or break anything, even though their state isn't totally consistent. They won't respond correctly to queries (e.g., querying for tasks in the milestone won't return affected tasks, since they aren't "really" part of the milestone anymore) but should behave normally other than that. So it's not critical to hunt down every single affected task.

Thanks for the report! This is a definitely a bug, and should be fixed later today once D15834 is reviewed.

This is supported, just not by the plugin you're using (which we don't maintain). Here's an example:

I'm going to merge this into T10748: the modern diffusion.repository.edit endpoint it provides is the pathway forward here.

I'm going to merge this into T10748. It should technically be fixed by D15829 on its own, but will be fixed even harder once we cut over to the changes in T10748.

I'm going to merge this into T10748: this should be fixed by D15829, but won't go live until after we cut over to the new UI as part of the changes in T10748.

When Phabricator used this UI, we consistently got feedback from many, many new users that it was overwhelming. In particular, it presented ~30 applications while the modern default navigation presents about ~10.

Ah, sure, that makes sense.

This one is obviously ghosts. How could this possibly be anything but ghosts?

I think it's maybe in the PHUIStatusView here?

This is now mostly built as a new "shadow UI" and we're nearly ready to cut over and start having it affect repository behavior.

This substantially exists at HEAD, but Diffusion doesn't actually use it yet.

I'm going to merge this into T10748, which has implemented these endpoints, although they won't be fully functional until we cut over to the new URI code, likely in the next week.

I'm going to merge this into T10366. This will be supported once we cut over to the new code there, likely in the next week.

I'm going to merge this into T10366. The changes there support customizing which URIs are shown as clone URIs, adding arbitrary new URIs, and disabling or hiding the first-party URIs.

I'm going to merge this into T10366. After D15822, this information is available via diffusion.repository.search by asking for the uris attachment. Note that:

Try that one instead.

Actually, this doesn't behave well with very long titles. Let me see if I can find an alternate fix.

Thanks for the report. This should be fixed in HEAD of master, and should promote to stable within 24 hours. Let us know if you run into anything else.

Can you point us at where in the UI these are used, exactly? Just want to make sure we're fixing the right thing.

This is the expected method.

It has the visible effect of removing the page header and footer.

The heuristic only triggers if the repository was previously empty. So it might possibly get a false positive on the very first pull request to a new empty repository, but should be fine after that.

Note that when you do this, you may generate a large amount of email you don't want, because you're adding commits to a repository which was previously marked as fully imported (it "completed" the import process when it was an empty, hosted repository). You may want to disable publishing in "Publish/Notify". See also T9554.

I can't reproduce this. Here's what I tried. First, I created a new, empty, hosted Git repository:

If you know the ID/monogram of the room (should be in the subject of any email you received, looks like Z123), I think you can also bin/policy unlock Zxxx it, which should make it public. Then you should be able to rejoin it.

@benjumanji, I added you to Community so you should have some new powers to abuse.

Great, I'm glad to hear things are working for you. Thanks for your help testing this out!

Oh, the actual implementation would be --revision (with a short option), I was just using --the-revision-for for clarity (or extra confusion?) in discussing the meaning/behavior of the flag.

Some earlier discussion in T5781, although I didn't really have a clear way forward at the time and still don't.