The software should have a canned response or a tick box to include a visible reader-facing signature.

[...]
I don't think that profile content changes happen so often that this would justify writing custom code (to parse and embed global userpage content in Phabricator) and maintaining that custom code.
Hence proposing status declined.

(Following that way of thinking, I opened this task.)

That talks about an eye being related to "watching" while "watchlist" is translated as "follow list" to some languages and has nothing to do with an eye. This is a valid concern.

Where a feature requires too much effort, is it not usually given low priority? So that if a volunteer wants to write such code, they have an opportunity.

To have a unified profile across Wikimedia sites, so that if I would like to add something new then I don't have to add it by hand in a global profile and in a phabricator profile.

What does "localizable" mean exactly in this context?

we're treating old versions of pages as canonical. For example, http://en.wikipedia.org/w/index.php?title=San_Francisco&oldid=652862076 sends that URL as its canonical when it should send http://en.wikipedia.org/wiki/San_Francisco. This is a specific case of the above issues.

I did try cpan today as well, but the internet connection drops before it finishes the required tests.

not packaged

I would say the way this software bottom-posts on forums which require top-posting is disruptive and without any workaround (other than people fixing it by hand). Would prioritizing it as High be pertinent here? Thank you.

it would be great to have that footer ("About · Subscribe · ...") as a translatable page or template of sorts

How may we require that a reasonable signature (in "person/entity (a link to a monitored talk page) TIMESTAMP" format) is always present?

(Please do not ping me, I have notifications disabled and only follow-up by hand -- please edit your comment and remove my nickname.)

https://ru.wikinews.org/wiki/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D1%86%D0%B0:Gryllida/js/feedbackstuff.js/doc is a javascript gadget to a similar effect. It adds a 'feedback' link next to the "username/prefs/beta/log out" menu.

Migration happened three months ago and if someone feels like fixing the migration script (that we do not need anymore) for whatever reasons, the code is there.

http://www.faqs.org/rfcs/rfc2821.html

The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. Mailbox domains are not case sensitive.

Please, let's consider not surveying people.

I'm changing the status to Open. This is something I'll do once only, here, as I feel I was misunderstood: What you suggested is a path to invoke UploadWizard from a sister project. I'm looking for paths to go to a sister project from the UploadWizard at Commons.

Oh, thanks. It is OK to merge with T802.

Project members and watchers are different concepts.

I think this is about simply linking to the list of project members and giving the current number of them. Rather than adding each one to CC.

Merge Low and Low-1.

Where a task is acknowledged as desirable, but a Team doesn't take it, I would personally leave "Priority: None", and mark it as "open". This would clearly distinguish it from "needs triage" tasks. Low priority should only be used for tasks the Team does take, but plans to do later, IMHO.

• "closing marginal tasks that clearly have little to no chance to be addressed ever" - This is naturally done during triage?
• We ought to not only "provide mechanisms for stakeholders to highlight the Low priority tasks that have a higher impact", but also the same for High priority tasks which have lower impact.
• And this — along with "connecting popular priorities with maintainers' plans" — ought not be restricted to stakeholders; we must encourage participation from anyone. Whether they run a big wiki, a small wiki, are a stakeholder or a random stranger should not matter.
  • In the unfortunate circumstance of us being intent on having a mechanism for stakeholders to highlight the priority tasks that have a higher impact, I highly recommend making "wikimedia-movement" a single tag without differentiating sister projects. That would be a big win. It would finally make us care of the sisters as well as of the big wikis such as English Wikipedia, and encourage resolving tasks in a way which is useful to all sister projects (if this is possible).
• I like the "reviewing contributions fast" idea. It means we ought to review patches from newcomers first. These probably just need a special tag.

This was previously discussed here:

• https://phabricator.wikimedia.org/T268 Decide on "Priority" field values for Maniphest tasks

True that, this was an invalid request. Thanks! (You may want to remove it, as it's documented anyway).

Re-opening per the comment above.

No, Nemo, you have misunderstood.

(Clicking "next" is annoying. Adding and removing images is a pain then; once I selected a licence, I have no way to go back and select another licence. Have you looked at imgur?)

To clarify: anybody should be able to set priorities. Team should have nothing exclusive or different, other than the fact that they work full time and get to do more things than an individual volunteer.