On Outbound Email rules, does the Do Nothing action neither send an email nor a notification?

Uh interesting - good to know for the future. So at least the button Mark All Read here in F3271029 should be visible for your case - as very minimal mitigation sub-task

The mark all read link in the notifications dropdown panel is always available. (It did clear the phantom notification.)

The current workaround is to wait for a real notification, to then finally be able to click the Mark All Read.

It happened to me but only in Wikimedia Phabricator, there I had a notification counter in the top-bar, but with no unread messages in the related list

I don't understand the problem described...

Search brings up rP70d67a3908b8: Fix the most significant "phantom notification" badness

Thaanks - please wait 7 days + 1 hour + 1 second + 42 milliseconds before landing to attract more Pòkèmòn reviewers

In T15203#21226, @valerio.bozzolan wrote:

(M is short for Mockup probably)

(M is short for Mockup probably)

I'm not familiar with MediaWiki's packages - the model I'm copying is VSCode.
My thought is that in the install manual we'll say "now run ./bin/extensions install phorge-recommended-extensions" (near the ./bin/storage) step, and phorge-recommended-extensions would be the equivalent of "extension pack" hosted on the default Extension Store, which is hosted here.
(VSCode also has "bundled extensions", which I think doesn't work for us because we use "clone the repo" as the primary distribution system).

In T16007#21223, @avivey wrote:

In T16007#21196, @Cigaryno wrote:

In T16007#21194, @avivey wrote:

Ideally, any current Prototype can be either promoted to Core, extracted to its own extension, or removed completely. Each extension/author can have their own policy on contributing.

Already, any new app that would be considered "Prototype" today should just go in its own extension, and we decided to remove a couple.

It depends on who on the wild (including large private companies developing closed-source software) is using prototype applications on Phorge. This should let us know if it should be promoted to core, separated into an extension, or removed completely if no one uses it (like Releeph and Phragments). Or even better, hold a Slowvote for each prototype application's future and possibly have Phorge's customers to vote (maybe notify as much as possible by creating a blog post about the vote to notify those who use the Atom feed).

I'm not sure that "usage" is really the best way to choose between "promote to core" and "extension"; The way I imagine it, in addition to the Core, we'll have a set of "highly recommended extensions" maintained, and a single step to install all of them when setting up a new machine. In that world, any app that can be separated out to an extension will be.
The prototypes can usually be curved out easily, without effecting the rest of the code.

In T16007#21196, @Cigaryno wrote:

In T16007#21194, @avivey wrote:

The "Prototype" concept was a way for Phacility to experiment with things without committing - but we have a different model today.

Really!? Phacility SaaS instances do not allow enabling prototypes and self-hosted Support (from the Support application on admin.phacility.com that was oddly marked as Prototype) likely wasn't even available for prototype applications.

On this server, we changed the config to /^(Q|V|M)\d$/ because we don't have P1 tickets.
I'm also not sure what M is short for.

To me, "obsolete" manes "no longer appliable" - basically, "the information in this page doesn't apply any more".
Some (made up) examples:

• "Can Phorge run on PHP 7.0?" (The answer is no, because of a specific bug in 7.0, which was EOL a long time ago)
• "I have this problem in the Chatbot app" (We've deleted the chatbot app)

In T15203#21219, @avivey wrote:

The V123 syntax is disabled by remarkup.ignored-object-names config by default; The default is /^(Q|V|M|P)\d$/ (basically anything starting with Q, V, M, or P), for "Q1" (biz-talk for April), "V1" (for versions), "M1" (for ?????) and "P1" (Jira for "important bug").

I'm honestly surprised about layout=inline working for {T123} - I thought is only works for images. But it can probably be made to work for Votes (or rather, all objects) like it does for tasks.

The V123 syntax is disabled by remarkup.ignored-object-names config by default; The default is /^(Q|V|M|P)\d$/ (basically anything starting with Q, V, M, or P), for "Q1" (biz-talk for April), "V1" (for versions), "M1" (for ?????) and "P1" (Jira for "important bug").

I now realize that this is not about hierarchy (documents below other documents) but about the Table of Contents within a single wiki page? You may want to edit the title.

What you see is 100% normal regardless of your pixel density, display size and resolution.
With a similar approach to T15920, this can be achieved. However, I think there is one disadvantage: text may be crammed with a side hierarchy, resulting in lots of newlines for documents with long titles.
You can create a task now that you are member of Trusted Contributors.

In D25889#24581, @aklapper wrote:

Hmm, maybe should not change ->setURI("/people/tasks/{$id}/") because there might be external third-party code relying on this?

In T16007#21196, @Cigaryno wrote:

It depends on who on the wild (including large private companies developing closed-source software) is using prototype applications on Phorge.

See T15501: Voluntary Usage Survey App basically.

Or even better, hold a Slowvote

Please no popularity contests (with even higher self-selection bias)...

Hmm, maybe should not change ->setURI("/people/tasks/{$id}/") because there might be external third-party code relying on this?

Changed the policy for file F3250825 to Public.

@vabocharov please set the view policy of F3250825 to Public.

Good afternoon!
I get it, if you go to Phriction > Welcome to the Forge Wiki, then the hierarchy of documents will be displayed at the bottom (the screenshot below is attached). You won't see this in your example, as there are no attached documents.

In T16007#21194, @avivey wrote:

My thought on this is that long term, we'll remove the concept of "prototype" completely in favor of Extensions.

Prototypes that need a long way before being promoted to Core are those that should be separated into extensions.

In D25872#23862, @valerio.bozzolan wrote:

In D25872#23861, @nib wrote:

@aklapper Would it make sense to move the branch-naming lines into a function in class ArcanistGitWorkEngine, since it the branch-naming is git-specific? E.g.

public function buildBranchName($task_ref) {
  $task_name = $task_ref->getName();
  // regex, preg_replace, trim, etc
  return $branch_name;
}

Probably yes so it's easier with Subversion and Mercurial in the future (?)

Probably something with "for task" in the name like buildBranchNameForTask($task_ref)

My thought on this is that long term, we'll remove the concept of "prototype" completely in favor of Extensions.
The "Prototype" concept was a way for Phacility to experiment with things without committing - but we have a different model today.

• Handle arc work for new and existing git branches

Handle arc work for new and existing git branches

In D25905#24572, @aklapper wrote:

@Cigaryno: Oops, I am sorry! I had forgotten that this proposal also existed as it wasn't linked under "Revisions and Commits" in T16007. My fault. :-/

@Cigaryno: Oops, I am sorry! I had forgotten that this proposal also existed as it wasn't linked under "Revisions and Commits" in T16007. My fault. :-/

Hej hej and welcome! I'm afraid I cannot really follow... In my understanding the hierarchy is expressed via the breadcrumbs navigation right below the top bar and not at the bottom, at least for a screen width of 513px and more?
For example if I go to https://we.phorge.it/w/changelog/next_up/ , see the Phriction > Welcome to the Phorge Wiki > Change Log > Next Up breadcrumbs.

Obsoleted by D25909: Diviner: Contributing Code: Update section on Prototype Changes. I think @aklapper should have instead commandeered this rev but it's still okay to have a new revision instead.

where did my closing brakets go?

In T16007#21080, @aklapper wrote:

I do not think changes are necessarily needed, because it already says "With rare exceptions".

Bug fixes and security patches are indeed exceptions but not rare exceptions, assuming they fix problems with rough prototypes.

sorry for the late reply.
This looks good to me.

Thanks for this patch! Kind reminder: if you touched CSS or JavaScript, please remember to also run this:

In T15450#16936, @Iniquity wrote:

I agree that an additional status is needed for closing when creating a task. Current statuses are not obvious

Uh! That's magic. Thanks avivey. Created here: H29 Phorge: add comment to remember "celerity map" - T15209

@valerio.bozzolan try to create the global rule now.

I agree this seems pretty fundamental.

I can’t think of a reason this would be happening other than a bug or database inconsistency.

Fix the URL.

Sounds good. It should have no CAPTCHA configured (maybe we.phorge.it needs CAPTCHA to reduce unused account creations) and just like on secure.phabricator.com (see this), there should be a notice for users willing to demo the software on the demo instance and not the upstream instance (in Phabricator you can create a Phacility test instance and even to this day, this is still possible).

If there's interest, I revived hach-que's old Docker setup and am updating it to work with Phorge because azure devops is killing my soul at work. It's suitable for both local dev environments (T15011) and production installs, and I'll be supplementing the repo with IaC for a production deployment (T15928).

Grazie milée!

Ah, it also works on my computer but really not relevant, just the patch description was in line with my business expectations

This is EXACTLY the kind of serious-business patch description that should be mandatory in every Phorge patch to speedup code review. Thanks my friend. asd

I didn't notice anything amiss!

Sure, let's try again, why not

Make arc lint happier