User:Panos Alevropoulos/test/Entry

This page documents my proposed changes for the "new entry" page. The form can be edited here. For technical details, check the Semantic MediaWiki test subpage here.

Entry form code

• Form:PanosTest

Resources

• https://directory.fsf.org/wiki/Free_Software_Directory:Participate
• https://directory.fsf.org/wiki/Free_Software_Directory:Workflow
• https://directory.fsf.org/wiki/Free_Software_Directory:Workflow/Entry

My suggestions

There are currently 9 categories of fields that the user needs to fill to submit an entry. I will comment on all fields, separated by their respective category. There should be a prominent notice that the user has to follow FSD's style guide. I also don't think the categories need to be numbered (numbers take up space anyway).

Unapproved entries

• Currently unapproved entries read that the submission is under review with direction to see the Discussion page for more info.
• Perhaps the discussion page can have the license check checklist?

I created a checkbox template here.

• We still have not settled on a means to track nonfree programs that may someday be free. Seems appropriate to include here as it might connect to this function for unapproved entries.

1. General info

• Name: OK
• Short description: OK, but why is the font smaller?
• Full description: The title of this field is a bit misleading, because the (i) pop up suggests that it should only include a "short summary". Since this field is the core body of the entry, it should be more clear what is expected from users to put there. I think a few paragraphs that describe the program look nice. The FSD probably shouldn't include detailed technical information. The FSD only informs that a free software package exists for specific use cases. Also remind people that, if they link to other free programs, they should enclose them in double brackets, e.g. [[neomutt]].
• Homepage URL: OK, although a lot of programs don't have any homepage. Maybe also mention that repo links are ok when there's no dedicated homepage. Rename to just "Homepage".
• Ver. download: The FSD should explain why it asks for a specific version download and not a general download page. I would also like to know if we can somehow automate this, because programs are updated all the time. Include instructions for abandoned projects where the last known free version can still be found on archive.org or the softwareheritage.org.

Updated thoughts: The FSD wants to document software with specific versions. Packages are updated all the time, so who is really going to keep track of all the changes? Also, the likelihood of a free project becoming nonfree is low. I suggest nuking the "version identifier" and "version download" fields, and instead use a "last free version" field for any project that turns proprietary for some reason.

New fields:

• Last free version: This should be OPTIONAL. Only needed if the project turned proprietary or is abandoned but otherwise accessible on archive.org or softwareheritage.org.

Moved fields (see Etc.):

• Version status: This should be kept, but renamed to "Maintenance status".
• Person info
• Relevant entries
• High priority
• GNU
• Decommissioned
• Keywords
• This is an extension/add-on/plugin to, This is an inbuilt extension/add-on/plugin to, Component programs

2. License

• License and version: OK, would really like to see all names be SPDX-compliant, but this isn't that easy for reasons I don't remember.
• License copyright: This needs additional explanation by a license check guide.
• License verified by: This field should automatically credit the person who checked the license like this: Panos Alevropoulos. This is very important, because the user page can include information on how to contact the person in case of dispute in regard to the license.
• License verified date: OK, puts the current date automatically, which is good.
• License note: This needs additional explanation by a license check guide.

New fields:

• Documentation license: If the FSD requires that documentation be free, why is there no field for this?

3. Categories

This is one of the best features of the FSD, but if we want to see people use it more, I believe we should restructure this and make it more intuitive. It's not clear what some categories refer to exactly.

Changes:

• Biology: Merge with Science
• Georgraphy: Merge with Science

4. GNU

It's completely unnecessary to have a separate category for GNU. Just move this field to General info.

5. Software prerequisites

• Prerequisite kind: Needs to explain the different "prerequisite kinds", such as the difference between "required to build"and "source requirement".
• Prerequisite description: Maybe rename this to "prerequisite name"? Users should be instructed to enclose text here in double brackets, e.g. [[rust]]. Also, software prerequisites look better in all lowercase I think.

6. Person info

These fields should also be moved to General info.

7. Resource info

• Resource audience: Some people use singular (User), whereas others use (Users). The style guide should address this (I saw somewhere that singular is preferred). A dropdown menu with several options would probably make more sense.
• Resource kind: Many options here, many of them probably never used. Needs directions from a style guide.
• Resource URL: OK

8. Etc.

This category is the most problematic of all. It has an ambiguous name and, although it contains many useful fields, almost all of them are lost because the list is way too long. Important fields should be moved to General info. There needs to be a different order and separate fields in different subcategories.

• Screenshots: This can only be used by privileged users for security reasons. Screenshots are rare, but maybe we should use them for very popular packages. Also, a field for captioning the screenshot would be nice for accessibility reasons, but also for giving credits to other packages, e.g. "Dolphin on KDE Plasma 5.24.4 with Breeze Dark theme".
• Is High Priority Project: Should definitely be moved to General info category.
• VCS clone shell command: OK
• Dev languages: This should be removed. It's already handled by Categories.
• Doc notes: Should be more prominent and renamed to "Documentation".
• Is decommissioned or obsolete: Rename to "Decommissioned" (it's not up to users to determine if a package is obsolete). This should be moved to General info. It should also prompt users to explain why it's obsolete in the full description of the entry.
• Donate: This should require only LibreJS-compliant websites.
• Microblog URL: Rename to just "Microblog". I think this is referring to networking sites like Mastodon. No one uses this, but it can be useful. The info popup is wrong (it's the same as for "donate").
• IRC fields: OK, but the info popup needs to be updated to mention libera.chat, not freenode. Also, not only IRC exists nowadays (what about Matrix, XMPP, etc?).
• Relevant projects: Move this to General info.
• Keywords: Move this to General info, but is it needed? It's for SEO, but FSF tech team should investigate.
• Version identifier: See notes in General Info.
• Version date: See notes in General Info.
• Ver. status: Move this to General info, see notes there.
• Version comment: Has this ever been used? Should probably delete this.
• Last review by: Obsolete, we can just take a look at the entry's history.
• Last review date: See above.
• Submitted by: This should be automatic.
• Submitted date: This should be automatic.
• User level: This is too vague and I don't see how this can be useful in practice. Does anyone search for "beginner" or "advanced" software? It should probably be deleted.
• This is an extension/add-on/plugin to, This is an inbuilt extension/add-on/plugin to, Component programs: These are complex fields, but I can see potential use. Probably move them to General info. The style guide could provide some directions.
• Paid support: I don't think we are in position to advertise other people's business. This should probably be deleted.
• Accepts cryptocurrency donations: OK
• Checksum, OpenPGP fields: These are security related, but I haven't seen anyone using them. I'm okay with keeping them, but I expect them to be empty all the time, because it takes time to check these (unless we provide clear directions on how to fill them).

9. Save

OK