Free Software Directory:Backlog active

⚠ Info

See our infrastructure plan.

Please report confidential or urgent issues to bug-directory@gnu.org.

---

ⅉ It is a good idea to read the manual of Template:BacklogIssue before editing the page. ⅉ

Free Software Directory:Backlog/gobutton

Free Software Directory:Backlog/summarybutton

Append the new bugs you find in the FSD to this page.
Remember to follow the participation guide and sign your contribution. Thank you!

The bugs are archived after at least one week from their resolution or if the bug cannot be identified due to lack of information.

Uncategorized

1. Is now solved (sysadmin: please execute runjobs.php when appropriate to apply the substitutions and allow for further development of this Backlog Task). --LorenzoAncora (talk) 14:07, 4 December 2020 (EST)

2. Is now solved (see Template:GNU_promotions). --LorenzoAncora (talk) 13:08, 4 December 2020 (EST)

3. Stalled by pt. 1.

Template:BacklogIssue

Is there a way for us to HTTP ping those without using JavaScript?
I think we'll need to add a dedicated script. --LorenzoAncora (talk) 15:26, 24 April 2020 (EDT)

David, clarification is required. Please specify the position of the site dumps. --LorenzoAncora (talk) 13:11, 14 June 2019 (EDT)

That will require a free SaaSS (like https://webchat.freenode.net/) but we don't recommend third-party SaaSS in general, however I think this would be ok if the FSF should embed a web-based IRC widget into something like irc://webchat.fsf.org/fsf (for the Directory) and irc://webchat.fsf.org/libreplanet (for Libre Planet). However, the listed web-based IRC clients are not compatible with LibreJS, that must be fixed first. The authors of these programs accept patches, perhaps the FSF can evaluate which client the want to use and patch it? Related: IceCat, Free web-based IRC client replacement for Mibbit needed. --David Hedlund (talk) 02:22, 31 March 2018 (EDT)

On second thought we should use a dedicated module, so we can enlist the translations on the left user bar. --LorenzoAncora (talk) 15:01, 15 May 2020 (EDT)

FSD:Backlog#Donald

(20:43:02) David_Hedlund: But it's still a unofficial release. I think we should discuss this policy.

Backlog Admin Group

A possible solution could involve defining a checkbox with opacity:0 (display:none doesn't work for this); make the tab title as a label for that checkbox; and style the tab content so that when the checkbox is checked, the contents show and all the rest disappears. --Adfeno (talk) 21:39, 1 May 2020 (EDT)

Please could you extend this issue by adding a link to a video/GIF which shows the steps to reproduce the bug in a popular web browser? --LorenzoAncora (talk) 08:29, 5 May 2020 (EDT)

We won't abandon the existing table layout, however there is no reason for not making it adaptive, as HTML tables can be stylized like any other element and are still fully supported.
I believe we should add a CSS fix for small-screen/mobile devices. Feel free to propose (a tested) one during the next FSD meetings. --LorenzoAncora (talk) 08:29, 5 May 2020 (EDT)

I do not agree with pt. 1 to 4 but I agree with pt. 5 and 6, at the following conditions: sum should be replaced with SHA or MD5 and "Test Entry" should be smaller and placed in the top-right angle of the form and not keyboard selectable. --LorenzoAncora (talk) 08:29, 5 May 2020 (EDT)

This does not seem the best solution, how about adding a clarification near the copyright widget? --LorenzoAncora (talk) 08:29, 5 May 2020 (EDT)

I agree only with pt. 1 and 4. We can do pt. 4 directly during the next meeting, but for pt. 1 we should take into account the DB. --LorenzoAncora (talk) 08:29, 5 May 2020 (EDT)

This issue was already solved in your absence during the latest FSD meeting (May the 1st) by fixing the existing CSS to guarantee correct alignment and subdivision. For now it would not be wise to change the UX so much, but I suggest to keep your tip here for the future. --LorenzoAncora (talk) 08:29, 5 May 2020 (EDT)

I fully agree and I believe all should be bounded by well defined rules.
Having such systems and workflows in place is fundamental. If necessary, I am also willing to mentor during meetings. --LorenzoAncora (talk) 14:45, 31 January 2020 (EST)

FSF

Some work, like modifying the source files of MediaWiki, cannot be done by MediaWiki users themselves. We gather such tasks here so the FSF staff can help us fix them.

This issue is blocking the translation team: without it, it is not possible to plan and assign translations, nor to prepare translators properly. This extension should be installed as soon as possible. --LorenzoAncora (talk) 04:17, 17 February 2021 (EST)

For the first case (existing entries with License field blank when edited with form), these entries do still have their old property value. This is due to the fact that such entries weren't updated after Update-the-license-field was solved. However, when viewing such entries, the information is displayed as expected. With this in mind, one can keep both an editing and a viewing tab open to ease the process of recollecting the old license to match the new one. Finally, provided no other change to page listing on License namespace is made, future revisions of an existing entry and also new entries should display the information fine both on the form and on the view page. --Adfeno (talk) 17:54, 18 December 2020 (EST)

There is already a page for that, Special:Ask. Unless you provide more details and examples on how this request could be different from what is already there, I consider this a wontfix. --Adfeno (talk) 17:59, 18 December 2020 (EST)

Template:BacklogIssue

I cannot use the tool mw.loader.load('//meta.wikimedia.org/w/index.php?title=User:Hedonil/XTools/XTools.js&action=raw&ctype=text/javascript'); in my User:David_Hedlund/common.js.

Hotcat is also pretty interesting: This code is MW version safe. It should run on any MediaWiki installation >= MW 1.15. Note that HotCat is supposed to run with or without jQuery, and also on older installations that do not yet have window.mw. - https://commons.wikimedia.org/wiki/MediaWiki:Gadget-HotCat.js

Suggested solution: I think SMW can evaluate unapproved/uncategorized entries. However, https://directory.fsf.org/wiki/Special:UncategorizedPages (and other #Special pages) are empty. --David Hedlund (talk) 15:39, 16 March 2018 (EDT)

Template:BacklogIssue

I consider this a wontfix since moving and making namespaces is expensive, the wiki administrators themselves must deal and better organize the structure they already have in meaningful ways, for example, avoid inserting a collection as a project team, since the goal of the collection page is to point to “curated” list of software for a specific purpose, not to give information of a said group that edits that page. --Adfeno (talk) 18:08, 18 December 2020 (EST)

The bold mark on pages without approved revisions was a direct request by RMS, motivated by practical reasons. I think we can improve its appearance by reducing its size and using gray in place of black, but changing the color scheme of the unapproved revisions might compromise accessibility; the robots.txt solution won't work, because the Robots Exclusion Standard doesn't support regular expressions and globbing: __NOINDEX__ should be the most appropriate solution; software Talk pages are already used to start the revision processes and to add administrative notifications, but I could attach an extra documentation link to unapproved entries, using JavaScript; I think it is sufficient that the warning shown on unapproved pages maintains a purely technical connotation. --LorenzoAncora (talk)

It was recomended by adfeno to make use of the Template:AttentionBox to increase visibility of an entry's status. --Craigt (talk) 13:32, 24 December 2020 (EST)

I don't think this is a good solution, for two reasons: the use of templates does not natively integrate with JavaScript or CSS and therefore would require manual changes to the code of the extension included in the instance, changes that would be difficult to maintain in the long term (also, using XHRs to download the template would degrade the loading performance); a big message saying "Warning!" violates the prerequisite of this Issue (The presentation of pending entries should not reflect badly on a program). I suggest to add a message like This page revision is not approved and may not represent free software. Please browse the latest revision. at the bottom of all old page revisions. I've produced a preview. My mantra is: let's preserve the existing UX as much as possible, adding changes gradually and unobtrusively. ;-) --LorenzoAncora (talk) 07:06, 26 December 2020 (EST)

It was suggested by ggoes, "I think "is free software" would be clearer than "represents free software" Represents makes me think of some kind of spokesman thing. --Craigt (talk) 13:32, 24 December 2020 (EST)

Ok, the message can be edited without any problems, but we must all agree in order to minimize changes over time. The main problem is that all pages are subject to review and approval, so saying is free software might not be always correct in each context. I think that if the current message is too formal, we can replace represents with contains or links to and its truthfulness wouldn't be reduced. Additionally, we might even think about centring the message on the page if it's not yet prominent enough. I've produced a preview of both changes. 🎅 --LorenzoAncora (talk) 07:06, 26 December 2020 (EST)

What about reversing this statement, using an alternative expression of the same fact? "We do not yet know if this page links to proprietary software!" I think that is very clear and is explicit in what it is warning of. --Freefish (talk) 13:00, 25th of January 2021 (GMT)

Hi Freefish, TY for the suggestion, however I think it's too specific to catch all our use cases (the Directory rejects all non-free software, not only proprietary applications) and it does not represent the same fact (the opposite of free is non-free). If the administration really feels the need to change the phrase, we could use "This page is a submission in progress.\nWe do not yet know if this page exclusively refers or links to free software.". Such a comprehensive statement should please and protect everyone. Craig, do you think this new phrasing is adequate? --LorenzoAncora (talk) 06:11, 29 January 2021 (EST)

I support the more comprehensive statement. However, I think we can provide even more detail. It should direct readers to the Discussion page for more information and include an explanation as to why we are taking this approach with in-progress entries. Craigt (talk) 13:38, 12 February 2021 (EST)

Good. The new message is online since the last meeting and no issue was reported. If there are no complaints, this Issue will be archived during the next meeting. --LorenzoAncora (talk) 04:35, 17 February 2021 (EST)

Regarding the presentation of this message, given that nearly all other visual elements in the Directory are left-aligned, centering the warning will not necessarily make it more prominent. In general, when adding emphasis to an inline element it is usually best to use HTML's <em> tag and let the user's browser choose how to display this emphasis. This is because it results in better accessibility and compatibility than with custom styling. --Freefish (talk) 13:00, 25th of January 2021 (GMT)

EM tags are forbidden/ignored in CSS content; also, inline elements cannot influence the absolute alignment of a widget and there is no actual evidence of an enhancement from an accessibility PoV. --LorenzoAncora (talk) 06:11, 29 January 2021 (EST)

I added a robots file a few weeks ago that should not index revision pages. I second adding `__NOINDEX__` to the template. Mmcmahon (talk) 11:15, 25 January 2021 (EST)

I changed the template call in category pages to just contain the breadcrumbs for the main page. That seems easiest, and to do what we want. this issue can be closed now. -- Sudoman (talk) 15:16, 10 February 2021 (EST)