Page MenuHomePhabricator
Search Advanced Search

Advanced Search
Use Results
Hide Query

Use the application-specific Advanced Search to set additional search criteria: Tasks, Commits. (More information)
  • T158359: Replace EditPage to decouple saving logic from edit processing and user interface
    • Task
    • ·Closed
    EditPage is very long and overly complicated, it even carries a Surgeon General's Warning... It combines the logic for attempting save of a page with the processing of the edit request and the outputting of the user interface. It is in dire need of refactoring, as evidenced by the multiple code comments there. It is going to be harder and harder to maintain in the future if we don't. However refactoring from within would make it difficult to keep the hooks working. I believe the class is not salvageable and we need to replace it entirely. We'll need to write hooks for the new classes and keep the old ones until extensions no longer create EditPage instances. I propose a new architecture as follows: - an Edit class to model an edit - an EditAttempt class that make the internal save attempt based on an Edit object - an Editor class that controls the user interface for editing - an EditFacilitator class that processes a form data into an Edit object, and mediates saving via EditAttempt - an EditView class that contains the UI elements for an editor class - and a static utility class EditUtilities.
  • T157882: Separate file patrol from regular patrol on the English Wikipedia
    • Task
    • ·Closed
    Files and regular wiki pages have little in common. Being trusted to upload files doesn't mean one is trusted to create new articles and vice-versa. Similarly, having the skill to patrol files doesn't mean one has the skill to patrol new articles and vice-versa. Thus it is suggested to split the ability to patrol files (patrol-upload) from the ability to patrol other pages (patrol), and the right to have one's files autopatrolled (autopatrol-upload) from the right to have one's other pages patrolled (autopatrol). This should help to reduce the backlog of unpatrolled files on non-Commons wikis since more people will be able to be granted patrol-upload or autopatrol-upload. [[https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive 138#Backlog_of_unpatrolled_files|Enwiki discussion]]
  • T157826: Spam blacklist should provide options like the Title blacklist
    • Task
    The title blacklist provides options applicable to a specific entry. The spam blacklist should do the same. Welcome options would be: - autoconfirmed: entry only applies to IPs and new users workaround: use of bots that revert the additions limitations of workaround: no warning, not user friendly, less efficient - warnonly: after seeing the warning, the user should be allowed to save nonetheless workaround: use of abusefilter limitations of workaround: difficult to handle huge lists, less efficient, condition limit - errmsg: provides a custom warning for this entry workaround: having a massive default message that tries to explain as much as it can limitations of workaround: obvious lack of usability/scalability
  • T157747: ?action=info incorrectly states that a new page is indexed when not
    • Task
    ?action=info checks page_props to detect if a page is indexed or not. So this will be incorrect on new unpatrolled pages. **Steps to replicate the issue** (include links if applicable): * enwiki * find a newish page in mainspace that is unreviewed. visit it. * go to "Tools -> Page information" **What happens?**: * "Indexing by robots" says "Allowed" {F35870515} {F35870517} **What should have happened instead?**: * "Indexing by robots" should say "Not allowed" or equivalent **Software version** (skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.): * My guess is PageTriage tweaks whether noindex is shown, but forgets to do a corresponding update to "Page information -> Indexing by robots". This should be fixed to avoid confusion. Possibly this can be fixed by using the InfoAction hook. See [[https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=764644558#noindex.2Cnofollow|a discussion]] where this came up. [[https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=780078928#Article_not_indexing_in_Google_despite_everything_in_order|additional discussion from merged task]]
  • T157715: Selective patrol: an AI-based system to prioritize patrolling of edits
    • Task
    Currently, wikis have the choice of implementing either new page patrol that allows patrolling new pages only, or full recent changes patrol. The problem of full RC patrol is that on big wikis, the absolutely massive number of edits to patrol makes the task almost impossible (the patrol of new articles is already heavily backlogged on enwiki). There is no way to find out (besides edit summaries and size changes) which edits need patrolling the most. With ORES, we have an additional indication that an edit is in particular need of patrol, but on wikis not using RC patrol, we still can't patrol the edits. Change tags allow to flag an edit in a particular way, and can help prioritize patrol, but we have the same problem as above. With deferred changes, we have an effective way to patrol those edits, but for various reasons the backlog //must// be kept low. So it is good to prioritize patrol of edits identified as highly suspicious by AIs, but not for those edits identified as somewhat suspicious. Therefore, we need a way to: - on wikis using full RC patrol UI, highlight some edits as being especially in need of patrol, end users would there have three filtering options: none, unpatrolled, needs patrol - on wikis not using full RC patrol UI, make it possible to patrol edits considered especially in need of patrol, end users would there have two filtering options: none, needs patrol. It should be possible to mark an edit as being in need of patrol either via: extensions: ORES, as it does already but this could be integrated in this framework, AbuseFilter, and via the API for bots. In addition FlaggedRevs should mark the edit as needing patrol when it defers an edit. So we would need three states of patrol: -1 for 'needs patrol', 0 for 'unpatrolled' and +1 for 'patrolled'. Unfortunately rc_patrolled is unsigned in the recentchange table, but if we can fix this, the implementation should be relatively straightforward.
  • T157659: Prefilled autosummary when editing old revisions
    • Task
    • ·Closed
    Having an autosummary prefilled when editing old revisions would be useful to remind the editor that they're editing an old revision, and to provide a default revert summary, as with undos. It could be e.g. "Reverted to revision 5493068 by ...".
  • T157524: Make autosummary for multiple revision undos
    • Task
    Multiple revision undos would also benefit from an automatic summary. FlaggedRevs does this already when rejecting edits, see RejectConfirmationFormUI class.
  • T157402: Provide a reliable way to pass information between hook handlers, "hooked" objects
    • Task
    • ·Closed
    Extensions use hooks to insert functionality at different places of mediawiki, but there is no proper way to share non-core data between hook handlers. Yet this is often needed, for example the Cite extension needs to use the same Cite object between its different parser hooks, FlaggedRevs needs the same FlaggableWikiPage object between its various hooks, etc. Workarounds against this limitation consist mostly in adding a custom field to the shared core object or making a static instance of the needed extension object. The former is a hack, even if allowed by PHP it should be avoided, and this can require cloning the objects or checking if they are the same. The latter is unsatisfactory, there may be several instances of the underlying core object or it may change in unanticipated ways (when anticipated, this requires clearing and recreating the instance). An additional issue is that all hook handlers are forced to be bundled together in a huge class of static methods. This has significant drawbacks: the code is hard to follow, the dependencies are obscure and it can't be unit tested. The underlying problem is the same: hook handlers are static, not linked to the objects they're meant to extend the functionality of. As such, we need to provide extensions with a unified and reliable way to pass information between hooks, and the flow of it should be clearer. One possibility is to "hook" an extension object to a core object, for example Cite to Parser and FlaggableWikiPage to WikPage. Then a hook run from the core object has its handler as a method of the hooked extension object.
  • T156877: Create a config object for each extension/skin during registration
    • Task
    • ·Closed
    It is possible to create a configuration object for each extension or skin during registration from their settings. It will be helpful for extensions to have an automatically generated config and that way, we'll be able to deprecate GlobalVarConfig.
  • T156810: Finish deprecation of RequestContext::getStats()
    • Task
    • ·Closed
    RequestContext::getStats() was deprecated in rECIR6a664900446cf968a688f886efe0128063a1f18d in favor of MediaWikiServices. The remaining uses should be removed and wfDeprecated added.
  • T156646: Make a config object for each extension/skin, deprecate GlobalVarConfig and RequestContext::getConfig()
    • Task
    With extension registration, it is now possible to gather the config variables of each extension/skin, separately. So we can make a HashConfig for the defaults of each extension and merge in the user defined settings. Furthermore, we can also make a HashConfig of core default settings then merge in the user defined settings. This means we can deprecate GlobalVarConfig and get rid of most globals. Globals would still be defined in local settings but unset after merging. RequestContext::getConfig() can then also be deprecated, especially as it doesn't depend on the request as noted in the file. We should instead provide some common objects like APIBase with a config accessor (itself implemented via a MW service). Some modules like RessourceLoader may even want to make their own config independently of the main config.
  • T155969: Allow CUs to view which IP addresses attempted to create a given account that was blocked by TitleBlackList
    • Task
    There should be a way in the checkuser extension for checkusers to see which IP addresses attempted to create an account that was blocked from creation by the title blacklist.
  • T155967: Replace IPs with "an anonymous user" in title blacklist hits log
    • Task
    Doing so would violate the WMF privacy policy (see T68450).
  • T155909: Provide contribs link in block logs similar to hist link in protection logs
    • Task
    It would be useful when investigating a past block to have the context of it in the form of the user's contributions prior to it. We could add a link to those in the block log. This is similar to the hist link of the protection log that links the article history preceding the protection.
  • T154637: Notify users when manually reverting to an older revision
    • Task
    This is similar to T153570, but for manual reverts to an older revision. This can be accomplished by setting a base rev id (without an undid rev id).
  • T154308: Provide history UI to undo multiple edits
    • Task
    Currently, it is difficult for editors to find out how to undo multiple edits at once. To do that, they need to view the diff for the selected revisions, then undo, and it isn't obvious that undo there will undo all intermediary edits, since in histories they don't. I've often seen users undoing one edit at a time in reverse order, which is a pain. So we should provide a way for users to undo multiple edits at once. I suggest a button next to the "compare selected revisions" one.
  • T154263: Deprecate ArticleRollbackComplete hook
    • Task
    • ·Closed
    Rollbacks shouldn't be treated differently by extensions from other multiple-revisions undoes. They can use the PageContentSaveComplete hook, provided we pass the current rev id as undid rev id.
  • T153570: Notify users when undoing multiple revisions
    • Task
    It is possible to undo multiple users using the 'undoafter' param. This is used by tools like Twinkle to undo multiple revisions. Currently, no user is notified when undoing multiple revisions since EditPage provides undidRev only when undoing a single edit. EditPage would have to provide it along with a new undidAfterRev.
  • T153567: Reverts with the API don't notify users anymore
    • Task
    • ·Closed
    Reverts with the API no longer notify users, see [[https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#No_notification_for_Twinkle_reversion|this report]].
  • T150594: Implement deferred changes on the English Wikipedia
    • Task
    There is unanimous consensus on enwiki to allow the AbuseFilter and bots to defer changes for review, and consensus to allow ORES to do so as well. Community decision: https://en.wikipedia.org/wiki/Wikipedia:Deferred_changes/Request_for_comment_2016 This is blocked on development, with the associated tasks being T118696 for bots and the AbuseFilter, and T150593 for ORES.
  • T150593: Make it possible for ORES to defer changes for review
    • Task
    There is consensus at https://en.wikipedia.org/wiki/Wikipedia:Deferred_changes/Request_for_comment_2016 to allow ORES to defer edits for review. This needs the main implementation of deferred changes at T118696 completed first.
  • T150086: Don't autopatrol autoreviewed users in protection-based configs
    • Task
    • ·Closed
    On one hand, when using RC patrol, it implies that autoreviewed users are autopatrolled on pages with pending changes, but not on others. This prevents regular patrol of those users (who often are merely autoconfirmed) on pending changes protected pages. On those wikis, the autopatrolled permission requires a much higher level of trust. On the other hand, when not using RC patrol, but only NP patrol, it creates automatic log entries that appear weird to end users, since they're not for new pages. They're completely unnecessary.
  • T148474: Notify users when one of their edits is reviewed
    • Task
    • ·Closed
    When a review occurs, the users that had their edits reviewed should be notified if echo is enabled. Indeed, they are notified when their edits are reverted (negative), but when their edits are accepted (positive) they should also know about it.
  • T147807: Add a toggle to show/hide protection log excerpt in edit window
    • Task
    The protection log excerpt shown when editing protected pages can be long and distracting, there should be a toggle for it. IMO it should also be hidden by default. This is what FlaggedRevs does with the stability log excerpt shown on pages with pending changes enabled.
  • T146793: Find a way for extensions using the API to make an action with their tag applied
    • Task
    • ·Closed
    Currently, extensions desiring to add tags while using a core API module cannot do so because the tags parameter allows only user-defined tags. Hence, they have to directly call ChangeTags::addTags in a differed update. This is suboptimal, notably because it can result in consecutive write to the DB table changetags. There should be a way in the API to allow extensions to add their tags. At least for APIEditPage. Affected extensions: visualeditor, wikilove, massmessage, maybe others.
  • T146578: Use API tagging to tag edits with visualeditor
    • Task
    • ·Closed
    The APIedit module now supports tagging, visualeditor should use this functionality rather than tagging the edit on its own (see "todo" comment in ApiVisualEditorEdit.php, now achievable).
  • T146290: Support arbitrary periods and multiple limits in account creation throttle
    • Task
    • ·Closed
    Support for arbitrary period of limits and multiple limits for account creation is needed before one can merge the Throttler and ping limiter.
  • T146287: Support group-based relaxing of limits in Throttler
    • Task
    This is needed e.g. for T85538.
  • T129918: Nested references don't work in mobile view
    • Task
    • ·Closed
    Nested references (i.e. [[https://en.wikipedia.org/wiki/Wikipedia:Nesting_footnotes|references within references]]) cannot be opened properly in MobileView. Clicking on them does nothing, unless the references section has been previously expanded, in that case it points to the references section rather than providing a snippet. ``` Test{{#tag:ref|This is a note.<ref>This is a nested ref.</ref>|group=note}} ==Notes== <references group=note /> ==References== <references/> ``` This is because the JavaScript to lazy load references is only bound to the page, but it should also run inside the reference dialog itself.
  • T129054: Math formulas can be unreadable in references in mobile view
    • Task
    When references containing math formulas are shown with JavaScript, the formulas can be unreadable. This the case in safari and in chrome. Example: https://en.m.wikipedia.org/wiki/Reflexive_space#Reflexive_locally_convex_spaces (click [17] - there is a hidden math icon at the end of the reference) {F3552458} = Preferred Solution Per @alexhollender_WMF in T129054#8363253 we would like to convert the reference drawer to use the gray background. This would require updates to the Drawer component. {F8722709} ----
  • T128208: Allow Cite extension to hook into header expansion
    • Task
    • ·Closed
    For T70324, Cite needs to hook into Preprocessor::expand when headers are made. It can't be made with the ParserSectionCreate hook since it's called much later in the parse, at which point all references have already been processed.
  • T128036: Allow to preview list-defined references in the section where they are defined
    • Task
    • ·Closed
    When defining references inside <references></references> tags, which occurs most often in the references section, section preview should allow to preview the references.
  • T127852: Publish of recent change for a log entry should be deferred
    • Task
    • ·Closed
    The publishing of the recent change for an edit is currently deferred. The same could be done for log entries, since it shouldn't block the request. This would require making change tagging directly in ManualLogEntry::publish (or to defer it).
  • T127848: Should be possible to associate a revision to a log entry without making it unpatrolled
    • Task
    • ·Closed
    Revision ids associated to log entries were introduced for T11501 to make uploads patrollable, but it has other uses cases (T70936, T72518). It should be possible to associate a rev id without making the resulting recent change potentially unpatrolled. Actions need a proper user interface before being made patrollable.
  • T127787: Strip markers in references data
    • Task
    • ·Closed
    References data is saved during parse and when {{#tag:ref|...}} constructs are used, themselves containing <ref> tags, strip markers will replace the embedded <ref> tags. This behavior can also occur with other tags but <ref> tags are the most important, since such constructs can occur when notes contain references, for example at [[https://en.wikipedia.org/wiki/Sea#Notes|Sea]]. Based on the transclusion count of [[https://en.wikipedia.org/wiki/Template:Refn|Template:Refn]], this affects about [[https://tools.wmflabs.org/templatecount/index.php?lang=en&name=Refn&namespace=10#bottom|9000 articles]] on enwiki.
  • T126607: Add a new level of article protection on en.wikipedia.org
    • Task
    • ·Closed
    See [[https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_129#New_usergroup_with_autopromotion_to_implement_arbitration_"30-500"_bans_as_a_page_protection|community discussion]]. It is requested that a new usergroup be added, autopromoted once after 30 days and 500 edits, and that a new userright e.g. `editrestricted` be created and added to this group, bots and sysops. Sysops should also be able to add/remove this usergroup. In addition, a new edit restriction level is requested, requiring the new userright to edit pages under this protection. The name of the usergroup hasn't been really discussed.
  • T126124: Users who do not have 'patrol' permission cannot filter out patrol log entries in logs
    • Task
    • ·Closed
    Considering how overwhelming patrol log entries can be, those users should also be able to view logs without them.
  • T126123: Logs of removed extensions appear in logs unformatted
    • Task
    • ·Closed
    Logs of removed extensions still appear in logs but are not formatted. See for example [[https://en.wikipedia.org/w/index.php?title=Special:Log&page=Wikipedia%3AGeneral+disclaimer|Article Feedback at enwiki]], [[https://www.mediawiki.org/w/index.php?title=Special:Log/*devunt&offset=20120925000958&type=&user=*devunt|FlaggedRevs at mediawiki.org]], and many others. This is very confusing and in my opinion, these entries should be removed altogether. In a sense, this is related to T44246.
  • T125329: Save references in page_props and cache
    • Task
    • ·Closed
    Saving references in page_props and a cache would allow to retrieve them efficiently through the API: T123290 and for section preview: T124840.
  • T124883: Heavy processing of page properties not needed in output should be deferred until LinksUpdate
    • Task
    • ·Closed
    Time-consuming processing of page properties needed for proper storage in page_props can be deferred until LinksUpdate, using the LinksUpdate hook.
  • T124882: Defer json encoding and compression of graph_specs property
    • Task
    Json encoding and compression of the graph_specs property, which isn't needed to output the page, can be deferred until LinksUpdate update, using the LinksUpdate hook. Json_encoding + gzencoding of data in the 64 KB range can take up to 20 ms.
  • T124880: Defer compression of templatedata property
    • Task
    • ·Closed
    Compression of the templatedata property, which isn't needed to output the page, can be deferred until LinksUpdate update, using the LinksUpdate hook. gzencoding of data in the 64 KB range can take up to 15 ms.
  • T124226: Allow to customize with css edit area of old page revisions
    • Task
    • ·Closed
    When editing an old revision, MediaWiki:Editingold might not be enough for some users, and some css to customize the font of the edit area may be worthwhile. This is already done for protected pages. See [[https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Eliminate_.22Edit.22_link_for_old_revisions|one such concern at enwiki]]. Fixed in https://gerrit.wikimedia.org/r/#/c/265375/.
  • T123747: Some reuploads can't be patrolled
    • Task
    Sometimes reuploads don't trigger a [Mark this file version as patrolled] link on the file description page although they are displayed at Special:NewFiles as unpatrolled. The link is correctly displayed for [[https://en.wikipedia.org/wiki/File:Power_Rangers_Dino_Super_Charge_logo.png.jpg.png|this file]], but not for [[https://en.wikipedia.org/wiki/File:Playlist-theverybestofyannicover.jpg|this one]], even though both are unpatrolled.
  • T123232: No documentation can be added to TimedText pages
    • Task
    Adding documentation to TimedText pages directly breaks their rendering. Yet it's important to add such information on occasion, particularly for copyright concerns, e.g. in case of copyrighted lyrics when fair use is claimed. A solution would be to display documentation subpages below the TimedText page, as is done by the Scribunto extension for Lua namespace. Links to [[https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Non-free_content&oldid=698989776#Fair-use_status_of_Timed_Text|original enwiki discussion]] and [[https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=699296957#Talk_header_for_TimedText_talk_namespace|village pump]].
  • T121177: Find some way to regroup related multiple low-activity log types
    • Task
    The number of log types has exploded in recent years (currently, there are 34 log types on enwiki). Some of those logs are related to a single subject, but are low-activity, examples: education program logs, and global logs (outside meta). It would make sense to regroup them by default: all education program logs, all global logs, but expand them if searching for one of them directly.
  • T119241: Allow autoconfirmed users to report edits to oversighters
    • Task
    This might be similar to the thanks extension, but instead with regard to problematic edits that should be reported to oversighters for hiding.
  • T118699: Simplify FlaggedRevs configuration settings for protection-based configs
    • Task
    • ·Closed
    Enabling a protection based config requires tweaking a large number of config variables that are not mmeaningful in this case. Simply setting $wgFlaggedRevsProtection to true should be enough for a protection-based config. Same for a config that would only use deferred changes (T118696), or both.
  • T118698: Add a hook after updating change tags
    • Task
    • ·Closed
    Adding a hook to the function that updates change tags would allow extensions to react whenever tags are added / removed from an edit or action. This allows in particular to implement deferred changes: T118696, but would likely have other uses as well. This is done in [[https://gerrit.wikimedia.org/r/#/c/218266/|commit 218266]].
  • T118696: Allow to defer 'suspicious' edits for review on any page in a reviewable namespace ("Deferred changes")
    • Task
    The purpose of this task is to enable within FlaggedRevs a way to defer for review edits identified as //suspicious// in some way, such as by being tagged. The defer can be either **passive**, in this case the version viewed by readers is still the latest revision but the page is listed at Special:PendingChanges, or **active**, in this case readers view the latest revision prior to the user being deferred (the one a rollback would revert to). If the user is the sole editor of the page, then it is listed at Special:UnreviewedPages. I've being working on an implementation of this concept in [[https://gerrit.wikimedia.org/r/#/c/218104/|commit 218104]]. The integration with AbuseFilter is T51770. Documentation available at [[https://en.wikipedia.org/wiki/Wikipedia:Deferred_changes|Wikipedia:Deferred_changes]].
  • T111664: Make it possible to tag Huggle edits
    • Task
    • ·Closed
    Since [[https://gerrit.wikimedia.org/r/#/c/188543/|this commit]], it is possible to tag edits from the API. Provided a custom Huggle tag is made at [[https://en.wikipedia.org/wiki/Special:Tags|Special:Tags]], it would make it possible to filter edits made by Huggle in recent changes.
  • T111663: Tag AWB edits
    • Task
    • ·Closed
    Since [[https://gerrit.wikimedia.org/r/#/c/188543/|this commit]], it is possible to tag edits from the API. Provided a custom AWB tag is made at [[https://en.wikipedia.org/wiki/Special:Tags|Special:Tags]], it would make it possible to filter edits made by AWB in recent changes.
  • T102420: Present to users only tags that can be added/removed at Special:EditTags
    • Task
    See https://fr.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=114641037&oldid=114013660 for an example of how wikis get around this issue. We should implement the fix in core.
  • T102186: wpExistingTags not passed in request if multiple revisions are selected
    • Task
    • ·Closed
    wpExistingTags is not passed in the request at Special:EditTags if multiple revisions are selected. It follows that the option to remove all tags cannot work. Also, users are prompted to add/remove tags that they cannot add/remove. I think we should check beforehand and only propose them tags they can add/remove. I had done this in [[https://gerrit.wikimedia.org/r/#/c/201905/|commit 201905]] but will split it off since it's not related to the main issue of that commit.
  • T100323: Do not show RC patrol UI to reviewers on reviewable revisions
    • Task
    When RC patrol is used concomitantly with FlaggedRevs (e.g. in its protection version), both the review interface and RC patrol interface appear on reviewable diffs. See [[http://www.mediawiki.org/wiki/User:Aaron_Schulz/FR_1.18_changes|background]]. Since reviewing has for effect to mark the reviewed revisions patrolled, I think we should not show the RC patrol UI since it is still present after the review even though they have been patrolled already (users might think they weren't patrolled, and do it for nothing). In core, we could ask extensions with the DiffViewHeader hook.
  • T98617: Make page moves patrollable
    • Task
    A move is a significant modification to a page and it should be possible to mark it patrolled. Recent changes displays the move log entry, and log entries in RecentChanges are always patrolled when saved, so we could make an exception for moves (when the user is not autopatrolled) and display a red mark. The RC entry could be patrolled from the footer of the moved page or the null diff for the move. This might be useful for T14363.
  • T98611: Allow tag editing from Special:Contributions
    • Task
    This would be useful in case of abuse or bot failure. Being able to do this in bulk would be preferable. This is related to T78092.
  • T97034: Tag log not included in public logs
    • Task
    • ·Closed
    The tag log is not included as part of public logs, it appears. So when one views logs for a user, logged tag actions aren't listed (one has to select "Tag log" to see them). ([[https://test.wikipedia.org/w/index.php?title=Special%3ALog&type=tag&user=Cenarium&page=&year=&month=-1&tagfilter=|example]])
  • T97013: Restrict changetags userright to sysops, edit filter managers and bots on enwiki
    • Task
    • ·Closed
    Per the original feature request on enwiki at [[https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive_117#Bot_tagging_of_edits|Bot tagging of edits]], this userright should only be provided to bots (so they can add tags), and to sysops (so they can remove tags if necessary). Since this was only a request for enwiki, we have no idea what other WMF wikis want as permissions, so I'd suggest using the same setup : restrict to sysops and bots. This should be done before the upcoming rollout of 1.26wmf3 on non-test sites.
  • T95319: Add 'problem' status for tags
    • Task
    We should add a 'problem' boolean status for tags, similar to the 'active' flag, for the benefits of T91425 and T89553. This is already implemented in [[https://gerrit.wikimedia.org/r/#/c/201905/|this patch]], but I'll split it in a new patch.
  • T94960: Activating tags previously defined and applied by extensions should not be allowed if the tag is not first deleted
    • Task
    Currently, tags that have been previously defined and applied at least once by extensions can be activated by admins, and therefore (when implemented) added by bots and users. I do not think this should be possible, unless the tag is deleted beforehand, since IMO we should mark a delineation between tags registered by extensions and those used by users and bots. And it might well be the case that the extension would reuse the tag in the future. A separate but related issue is that user defined tags with no hits can be both deleted or deactivated, with the same end result. We shouldn't allow them to be deactivated. We might do this with a new field vt_active in the valid_tag table, set to 1 (active) when a tag is created by an admin. A tag can be deactivated only when stored in valid_tag with vt_active set to 1 and it has been applied at least once. And it can be activated only when stored in valid_tag with vt_active set to 0, i.e. only tags created by admins that were subsequently deactivated.
  • T94214: Abusefilter group for testwiki
    • Task
    • ·Closed
    Some users are interested in just testing filters at testwiki but since only admins have access to those there, the need to grant the full admin package to those users is an impediment. We should have a group just for editing filters, as several wikis have already. See recent [[https://en.wikipedia.org/wiki/Wikipedia_talk:Edit_filter#Request_for_permission_for_PhantomTech|enwiki]] and [[https://test.wikipedia.org/wiki/Wikipedia_talk:Requests/Permissions|testwiki]] discussions.
  • T93798: Give patrol to reviewers on testwiki
    • Task
    • ·Closed
    Currently, no usergroup other than sysop has 'patrol' rights on testwiki. Some users want to test NP or RC patrol but giving out sysop rights just for this is overkill, see [[https://test.wikipedia.org/wiki/Wikipedia:Requests/Permissions/Prianka|this request]] and [[https://test.wikipedia.org/wiki/Wikipedia_talk:Requests/Permissions|related discussion]]. We can grant this to the existing reviewer usergroup. Having a separate group seems unneeded.
  • T91535: Performance issues with tags
    • Task
    • ·Closed
    Since the ListActiveTags hook was implemented, I noticed a significant increase in loading time at Special:Tags. Extensions use this hook in addition to the ListDefinedTags hook. This means they must hit their database twice for many tags. In order to implement T89553, we need a way for extensions to specify which tags should be 'patrollable', or for T91425, which tags are considered to indicate a 'problem'. If we used the same scheme, this means we would have to create yet another hook listing these. This would only increase the performance issues, but in that case it would have a greater impact since the list of 'patrollable' tags must be fetched when displaying recent changes to users who can patrol (it would be cached, but still). I think we should completely change the approach and instead use a single hook "ListDefinedTagsWithParams" that provides the tag names as //keys// and an array of params as //values//. 'active' would be one such param. To get the list of all defined tags, we use array_keys. To check if a specific tag is defined, we use isset instead of in_array. We would need to hit the database only once and could get all the relevant data in one go. Having these keys is also going to be faster when making lists, since array_intersect and array_diff are just as inefficient as in_array. I think this will significantly increase loading time at Special:Tags and make it possible to efficiently fetch patrollable tags for display in revisions. Updated table after comments 1, 2, 3. The `active` status is passed as a param and the (int) param for "importance" is replaced with a (bool) `needcheck`. Also added (string) `source` for name of the extension and (array) `refs` for passing additional params like abuse filter ids. Updated again after patch set upload. 'needcheck' replaced with 'problem', 'refs' with 'msgParams'. Adds 'canDelete'. | //key (tag name)// | //value (array of params)// | //result// | `visualeditor` | array( 'source' => 'VisualEditor', 'active' => true ) | active, not patrollable, not listed at Special:ProblemChanges | `visualeditor-needcheck` | array( 'source' => 'VisualEditor', 'active' => true, 'problem' => true ) | active, patrollable, listed at Special:ProblemChanges | `possible vandalism` | array( 'source' => 'AbuseFilter', 'active' => true, 'needcheck' => true, 'msgParams' => array( 12, 45) ) | active, used by abuse filters 12 and 45, patrollable, listed at Special:ProblemChanges | `OAuth CID : 457` | array() | inactive | `OAuth CID : 509` | array( 'canDelete' => true ) | inactive, can be deleted by sysops Hook name : **ChangeTagsRegister** Available params : (bool) `active`, (bool) `problem`, (string) `source`, (array) `msgParams`, (bool) `canDelete` The hooks ListDefinedTags, ChangeTagsListActive and ChangeTagCanDelete should be deprecated eventually. ChangeTagCanCreate and ChangeTagAfterDelete are preserved.
  • T91425: ProblemChanges should only filter for tags indicating a 'problem'
    • Task
    • ·Closed
    Special:ProblemChanges should filter only for tags intended to draw attention to potentially problematic edits, not all tags (since there are many innocuous tags like 'HHVM', 'VisualEditor'). I think this should filter for tags defined as 'important' in [[https://gerrit.wikimedia.org/r/#/c/190656/|commit 190656]]. These are tags that should prompt a patrol for T89553.
  • T91249: Allow to configure display of flaggedrevs notice based on sync status
    • Task
    • ·Closed
    Some wikis want to configure the FlaggedRevs notice being displayed based on sync status. On enwiki for example, a custom protection notice is added for pending changes protected pages so the default notice on the stable page is unneeded duplication when synced. This would also solve the most important part of T75931. Commit for this : [[https://gerrit.wikimedia.org/r/#/c/189185/|189185]]
  • T91212: Error message displayed twice when moving to an edit-restricted title
    • Task
    • ·Closed
    When a page is moved to a title restricted with 'noedit', the error message is displayed twice.
  • T90841: Creating a tag named "filter" results in a conflict with system message tag-filter
    • Task
    The mediawiki page 'tag-filter' is used as a system message, so creating a tag named "filter" results in a conflict for its description. Same goes for "filter-submit" and "list-wrapper". All other messages use "tags-".
  • T90350: Change tags created by inactive OAuth applications should be deletable
    • Task
    The tag associated to a OAuth app cannot be undefined by the app publisher. There should be a way to undefine the tag so it can be deleted. At present, old inactive OAuth tags applied at least once remain at Special:Tags and there's no way to avoid that.
  • T90349: Deleted abuse filters should undefine tags
    • Task
    • ·Closed
    Tags added by an enabled abuse filter are defined and active. Tags added by a disabled abuse filter are defined and inactive. Tags added by a deleted abuse filter are defined and inactive too, they should instead be undefined. This way they can be deleted without having to search for the responsible abuse filter and un-define the tag manually (and they can later be un-deleted and re-enabled, without needing to re-add the tag manually).
  • T90310: Automatic tagging of cross namespace moves
    • Task
    • ·Closed
    This would be useful to check on pages moved into a namespace of interest (typically mainspace). If cross namespace moves are tagged, we only need to filter the namespace and we get all of those. They can be patrolled if patrolling of tagged changes from T89553 is enabled. This could probably be done directly when performing the move, after the null revision is created. It should also autopatrol if the user is autopatrolled. Abuse filters were created for this, but this isn't satisfactory for the same reasons as those mentioned in T73236.
  • T89716: New Page patrolling user preference option not shown when RC patrol disabled
    • Task
    • ·Closed
    Is there any reason to not show the user preference option to hide patrolled pages at Special:NewPages when RC patrol is disabled ? Shouldn't this check for NP patrol instead ?
  • T89616: Autoreview of reverts should be separable from autoreview of edits
    • Task
    In T59073, it was requested to allow autoreview of reverts to stable ids for reviewers when performing non-rollback reverts. Commit 106737 allowed this by making a sha1 check if the baseRevId check failed, however no userright check was added. This means that any autoreviewed user, so on enwiki, any autoconfirmed user, is autoreviewed when reverting to a stable id, meaning they can reject changes. This possibility was explicitly rejected when pending changes was enabled, for being too abusable, giving the upper hand in disputes, and for the difficulty in detecting such cases. A permission check for either 'review' or 'rollback' should be added for non-rollback reverts (in addition to 'autoreview'). A few refs, [[ https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Poll | here ]] is the poll for the original proposal, which is [[https://en.wikipedia.org/w/index.php?title=Wikipedia:Flagged_protection_and_patrolled_revisions&oldid=277904350|here]]. Note that it says "a new edit is visible immediately if the previous version is already reviewed; otherwise[5]not visible to readers by default until reviewed by a 'reviewer'". We wanted autoconfirmed users automatically accepted for their own edits, but not when reverting other users' edits, the later allowed only for privileged users (with rollback or review). But I've just noticed that the baseRevId check can be evaded since semi-automated tools like Twinkle can provide it, so this problem goes back to before commit 106737.
  • T89553: Recent changes patrolling limited to tagged changes
    • Task
    • ·Closed
    This is a request for a form of recent changes patrolling where only tagged changes would be marked as needing patrolled (outside new pages), as I suggested in T20670. This would be useful to determine if a tagged change has been dealt with or not, which cannot be achieved with the current implementation when RC patrolling is disabled. The native mediawiki patrolling feature seems to fit very well for this use - from a diff one can mark a change as patrolled and rollbacking marks a change as patrolled. I've uploaded a patch that implements this. This requires RC patrolling enabled, then enabling tag patrolling limits RC patrol to tagged changes. A list of tags to ignore can be defined in the config, typically tags applied for information or research purposes (e.g. HHVM, visualeditor), not anti-vandalism.
  • T88771: Allow manual tagging of admin actions
    • Task
    It is difficult to keep track of admin actions by reason, which is particularly relevant for page and revision deletions, but also for protections and blocks. We have a native drop down menu with default summaries that admins can select. Those are specified in mediawiki messages, respectively [[https://en.wikipedia.org/wiki/MediaWiki:Deletereason-dropdown|Deletereason-dropdown]], [[https://en.wikipedia.org/wiki/MediaWiki:Revdelete-reason-dropdown|Revdelete-reason-dropdown]], [[https://en.wikipedia.org/wiki/MediaWiki:Protect-dropdown|Protect-dropdown]] (also used for pending changes) and [[https://en.wikipedia.org/wiki/MediaWiki:Ipbreason-dropdown|Ipbreason-dropdown]]. I think we should allow attaching of one tag (or maybe more than one) to each of the dropdown item, simply by editing those mediawiki pages, provided the tags are defined at Special:Tags (more on this at T20670). The tag(s) to apply may be specified after each dropdown item, separated by a special character sequence, say /*/ (we may not need to modify Xml::listDropDown, the tag may be left apparent in the menu). There should also be a way to specify an "Other reason" tag (when no drop down item is selected). When an action is performed with a drop down item, the text of wpDeleteReasonList is split into the reason text (before /*/) and the tag(s) to apply (after /*/); there is a check that the tag(s) is(are) defined, and the action is tagged. One issue is that the 'delete' button is often replaced via javascript with a version where wpReason is prefilled with one of those reasons, such as when there is a speedy deletion tag or AFD template. It wouldn't work for those, but it may be fixed by allowing pre-selection of a wpDeleteReasonList option in urls. The function Xml::listDropDown already contains a 'selected' parameter, so it may be filled at Article.php with a url param.
  • T85372: Add support for per-category editnotices
    • Task
    To avoid use of a js hack and for increased compatibility, such as with visual editor (cf T56029), this is a request to support per-category editnotices. This had already been discussed in T20596, but the prospect of extension PageInCat being implemented, even for mediawiki pages, seems remote.
  • T78491: Saving without leaving visual editor
    • Task
    • ·Closed
    In order for visual editor to function smoothly on large articles or in a context of a high editing volume, there are two issues that need to be relieved : performance, as it can take a while to load visual editor on an article of large size, even when it was already loaded once, and edit conflicts, as they are quite regular on heavily edited articles, and it is necessary to use wikitext editor to resolve them, defeating the purpose of having a visual editor. This would be pretty much required in order to achieve a successful implementation on wikis like the English Wikipedia. The possibility to save an edit without leaving visual editor (meaning there would be two save buttons, one staying on VE and one leaving VE) would help on both counts. Indeed, it can take a while and be a hassle to (1) save the edit (2) load the saved page (3) relaunch visual editor (4) load visual editor. This means users are dissuaded from saving often, which goes against the very common habit of making several small edits rather than a big one, and increases the risk of edit conflicts. If a user could simply (1) save the edit (2) update the visual editor window with the edit and non-conflicting intermediary edits if any, it would be much less of a hassle for the user and the loading time could be optimized by only reloading the updated elements.
  • T78490: Image search by file size
    • Task
    • ·Closed
    A user friendly option to search multimedia by file size would be nice. Very often users want only images with a high resolution. I would suggest a dropdown menu with only four choices : all (default), large, medium and icon/small (as Google Image does). This doesn't need file metadata, only the file size, which is displayed in searches.
  • T78489: Multimedia search by copyright status
    • Task
    An option to search multimedia files by copyright status in a user friendly way would be nice. I would suggest a dropdown menu as in Google image, we could have public domain, cc by sa, and such. I think the best way to check copyright status would be via multimedia data. But since this is still in development the check may be made via categories.
  • T78323: Option to hide minor bot edits from watchlist
    • Task
    We can hide bot edits, we can hide minor edits, but we cannot hide edits that are marked as both minor and bot. This would be very useful because : - hiding minor edits is quite dangerous because registered vandals can mark their edits as minor, and rollbacks are minor too, yet they indicate the edit has been dealt with and is no longer a concern - hiding bot edits can be counter-productive since often bots perform edits that we should know about, for example page tagging, removing reported users at vandalism boards (which indicates they have been dealt with), etc (I can give more examples if you want), and sometimes edits we don't need to know about (adding date parameters, archives, etc). Generally, a bot will mark the edit as minor if we don't need to know about it, and not mark it as minor if we should know about it, and also mark it as non-bot if it's an atypical bot task (minor, e.g. vandalism reverts or non-minor, e.g. vandalism reports). So, for a lot of people (admins in particular), the only edits that should be hidden are minor bot edits.
  • T76968: Internal links to the current page (sections, references) don't work in media viewer captions
    • Task
    In thumbnails in media viewer, links to other pages work, but links to the same page don't work, for example section links or references. The links are put in the browser url, but not loaded. This behavior is consistent among browsers and devices (tested : firefox and chrome on windows, safari on ios, chrome on android).
  • T76384: Education Program article log should be an event for EP page not article
    • Task
    • ·Closed
    The log is of interest to the EP page and should be an event for it instead of the article, otherwise the people working on it have no way to know about those (the logs are spread out over plenty of articles). On the other hand, editors uninvolved in the EP who are watching the affected articles get all those notifications but it's of no interest to them, we've got repeated complaints about those.
  • T76301: Remove all proxy blocking functionalities from mediawiki core
    • Task
    To conclude the work started in T56597, I think the remaining proxy blocking functionalities should be removed from mediawiki core. The settings using this are $wgProxyList and $wgEnableDnsBlacklist, and there is an associated proxyunbannable userright. WMF wikis don't use this, $wgProxyList refers to mwblocker.log which does not exist in wmf-config, and a couple of wikis have $wgEnableDnsBlacklist set as true but don't seem to actually use it. WMF wikis use the TorBlock extension instead, so all that it does for end users is creating an unused userright. I think that all wikis should be able to choose whatever proxy blocking extension they want, and so there's no need to have anything in mediawiki core.
  • T76299: Option to group consecutive edits by a single user in expanded watchlist
    • Task
    For increased readability, an option to consolidate together all the consecutive edits by a single user could be added to watchlists. The appearance would remain the same except for a notification of the number of edits, and the edit summary would be the one for the last edit. If an edit has been marked as visited in between, the edits should be split in two groups (one before visit, one after visit).
  • T76266: Allow autoconfirmed users to move without leaving a redirect a page that they have recently created
    • Task
    The issue which precludes granting supressredirect to autoconfirmed users is that old pages may have links that would get broken. On the other hand, the main use case for moving without a redirect is when a user creates a page with the wrong title and has to move it, which then requires them to ask an admin to delete the useless redirect. So it makes sense to allow the creator of the page to move it without leaving a redirect when it has been recently created (say, 24 hours). (It would also make sense to allow it for old pages in their userspace (e.g. draft articles) but that's a special case of T71162.)
  • T76263: Rate limit move-subpages and grant to all autoconfirmed users
    • Task
    Rate limiting move-subpages was proposed in T16356 but not implemented because it was thought to excessively limit autoconfirmed users' ability to move subpages. It turned out that this was abused for page move vandalism anyway, so it was restricted to sysops. Making this rate limited and available to autoconfirmed users would greatly help on projects like wikibooks since books have plenty of subpages, and help in general on all projects with talk subpages and template/module moves, without any increase in risk. Using the rate limit would also easily allow to increase the limit for a particular trusted usergroup, such as reviewer on wikibooks.
  • T76205: Allow to specify on each project if a non-local interwiki should add an external link icon or not
    • Task
    • ·Closed
    There is concern on wikipedia that not showing the external link icon for some external sites with interwiki shortcuts (such as wikihow or wikia) is misleading to the readers and is abused for promotional purposes. We shouldn't break legitimate existing links on other projects, so could we add a configuration variable that can be tweaked on a per-project basis ?
  • T76067: Display in watchlists only a specified number of already visited edits for each page
    • Task
    There are two extreme options in watchlists : either only the latest edit to pages are shown (default), or all edits are shown (expanded watchlist). It would make sense to have a middle ground, and be able to specify in options the number of already visited edits to each page that should be displayed on one's expanded watchlist. If I choose 0, then only unvisited edits would be displayed, while if I choose 1, the last visited edit for each page would also be shown, and so on. When the option suggested in T76299 is enabled, a group of consecutive edits by a single user should count as one.
  • T76054: Remove show/hide patrolled edits from watchlists if patrolling is disabled
    • Task
    • ·Closed
    We don't use patrolled edits on wikipedia, so this should be removed from watchlists. This does nothing, just confuses users. It's not in recent changes.
  • T76053: Specific userright to bypass $wgAccountCreationThrottle
    • Task
    Noratelimit allows to bypass $wgAccountCreationThrottle and is granted to account creators for this reason. It has the unfortunate side effect of removing rate limits related to moves (which may be even more problematic if we give a rate limited move-subpages userright to autoconfirmed users). So as has been done with tboverride in T24141, a userright allowing only to bypass $wgAccountCreationThrottle and nothing else should be created. I leave it to your discretion if noratelimit should still allow the bypass or not (in the later case, sysops should have the new userright too).
  • T76050: Grant tboverride-account instead of tboverride to account creators
    • Task
    • ·Closed
    Now that we have template editors on wikipedia, it is no longer of any use to have tboverride for account creators, and they should be granted tboverride-account instead to avoid unnecessary risks.
  • T75931: Deactivate pending changes user interface when the edit protection is at the same level or higher
    • Task
    Sometimes we have to temporarily semi-protect a pending changes protected page due to really excessive vandalism, but we'd like to keep the stable settings unchanged for later, or we temporarily semi protect a page and also add pending changes protection but a bit longer to test the water. So when a page is both pc-protected [autoreview=autoconfirmed] and semi-protected (or higher), pending changes shouldn't be visible, in the sense that we don't get the pc icon at the top right of the article and the pc edit-notice. For [autoreview=reviewer], it should deactivate on fully protected pages only.
  • T75648: Link in block log to immediately preceding contributions
    • Task
    • ·Closed
    For the same reasons that the protection log provides a link to the page history immediately preceding the protection, a link in the block log to the user contribs immediately preceding a block would come in handy. -------------------------- **Version**: 1.25-git **Severity**: enhancement
  • T75417: Whether or not the user recently hit the spam blacklist (abuse filter)
    • Task
    It would be helpful to know if the user recently hit the spam blacklist. For example, to detect spammers trying to get around it or moving to other urls. I think this should be feasible now that there's a log of spam blacklist hits.
  • T75416: Remove EducationProgram rights from sysop
    • Task
    • ·Closed
    The sysop usergroup shouldn't have any education program userrights, since those are very specialized and already possessed by course coordinators. If any sysop decides to work in this area, they should grant themselves course coordinator. This way, there can be an exhaustive and updated list of course coordinators, which users can rely on if they need assistance. Indeed, if the relatively small number of sysops working in this area have no need to add themselves, most of them won't, so users won't know about them, and course coordinators would be too few. It is precedented, the extension abusefilter does that for example with abusefiltermanager. As an aside, ep-bulkdelorgs is missing from course coordinators. -------------------------- **Version**: unspecified **Severity**: normal
  • T75414: Remove proxyunbannable from core
    • Task
    • ·Closed
    Proxyunbannable is a userright granted to sysops by [[mw:Extension:AutoProxyBlock]]. But this extension is not used on WMF wikis, which instead use [[mw:Extension:TorBlock]], with torunblocked as equivalent. Torunblocked is not granted to sysop, so they cannot edit from tor. However, for some reason proxyunbannable appears in the listed rights of sysops, with the description "Bypass automatic blocks of proxies". This led to some confusion among users. Since it doesn't seem to have any use, it would be best to remove it. -------------------------- **Version**: wmf-deployment **Severity**: enhancement
  • T75114: Add user rights management link for admins at Special:Listusers
    • Task
    • ·Closed
    Since [[Special:ListUsers]] is often used to remove redundant usergroups, it would be time saving to have a direct link to user rights management for sysops. -------------------------- **Version**: 1.25-git **Severity**: enhancement
  • T75110: Magic word checking abusefilter flags
    • Task
    • ·Closed
    To sort out abuse filters and for maintenance on project pages and at [[Special:Tags]], it would be useful to have a magic world indicating the flags of abusefilters : whether they are hidden from public view, enabled or deleted. For example {{#abusefilterflag:hidden|546}} would return true if abuse filter 546 is hidden from public view, false otherwise. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T51787: Number of intermediary edits and of users having edited at MediaWiki:Revreview-update
    • Task
    It would be nice to have the number of users having edited in between as a variable for [[MediaWiki:Revreview-update]]. This way we could add a notice when multiple users have edited, it would be more visible than the info at [[MediaWiki:Diff-multi]], and save time for reviewers. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T51770: AF action to temporarily enable pending changes
    • Task
    The idea of deferring suspect edits for review has been suggested and found support on several occasions. The AbuseFilter provides a way to check edits and FlaggedRevs a way to review revisions, it seems sensible to combine in some way those two extensions for that purpose. In the linked page, I suggest that a new AF action be created: to enable pending changes on an article where an edit triggers the filter, before the edit is saved, so that the edit will be marked for review (the prior revision being reviewed automatically). The problem is that we want this to be temporary, a way to achieve this is by automatically removing pending changes as soon as the last page revision is reviewed. If possible it could be removed only after a brief cooldown period following the review, that could be fixed maybe per filter (to fend off repeated vandalism attempts). In order to inform reviewers, it may be good to display by default the PC config log when reviewing pages, considering it's not particularly obtrusive. The AF would log the action with a link to the triggered filter and its name, but wouldn't edit the page. For now, I think we can consider AF enabling only level 1 PC protection (autoconfirmed users are autoreviewed), to avoid complications on pages already on PC level 1 since the AF would have to restore the original setting. I'm sure this would gain consensus on en.wp if this or a similar implementation is possible. -------------------------- **URL**: http://en.wikipedia.org/wiki/Wikipedia:Deferred_revisions
1
2
Next
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL