Free Software Directory:Bugs
Bugs and suggestions
- Proposed features for the FSD
- Category browsing
- Set up RT for bug tracking and tiket making
- need to create "Category:Review-triaged" once RT has been set up.
- need to implement mass-emails about email verification, and directions for changing preferences.
Turn off 1,000 character limit for stringsThis was relate to a bug in MediaWiki, that has been fixed in an upgrade.
- Turn off error/warnings in SMW
- Add/update GNU packages
- Searching for "python" or "ruby" shouldn't lead to "License:Python" or "License:Ruby"
- "Preview" button does not work for Template:Entry. It shows the unedited version, but I don' think there is a way around this from our end, as the displayed values are based on a query of the saved page.
"Edit with Form" doesn't allow one to update the "last reviewed by" field
List of categories on Main_Page is too longThe layout has changed, an is hopefully more usable now.
fix the program tagging, so all programs are included in the main page redesign.This issue has been worked around.
Update the Form:Bug report to include the Category:Bug_report tag through a template.
Then update the pages in the Category:Bug_report name-space to visibly contain the category tag.
Then update Template:Bug_report to not include it automatically.
Should Category:Alert be changed like this as well, so we can distinguish new alerts from old ones? Done: one can change the "Nonfree" template field to "completed".
Make sure that the Bug_report pages and Review pages have links that are easily accessible by contributors.See FSD:Workflow.
For pages in Category:Review, we should have a link to create the relevant page (such as Review:xprog -> xprog) with Form:Entry if it doesn't already exist. We would need to use regular expressions to cut of the "-REV-ID-1" stuff. (or we could just set the proper pagename value as a property when Form:Submit is called.)
Rename the "Editor" property to "Editing", etc. (because the "Use" property is its parent, and its related value is "Editing", not "Editor". There are multiple instances of this dual naming.)Actually, Use: is not its parent. That property value refers to Audio editing (which is annoying because mixing, etc. also appears in Use: ).
Verify that '-'s have replaced spaces in all properties and their values.The issue was with Concept page names, which has been fixed.
- Make sure that program names submitted through Form:Submit don't have leading or trailing spaces.
FSS subscribe box points to the wrong place (should point to <https://crm.fsf.org/civicrm/profile?reset=1&gid=31">, not lists.fsf.org.
- We should be able to easily browse to all categories from an entry
- Fix link at bottom of page that links to "Free Software Directory:Copyrights" (in Style files)
- home page of every GNU package (yes, really) to be listed as <http://www.gnu.org/software/PKGNAME>
- conditional statements should be created for various properties (e.g., "Audio:mp3" should result in "works-with::Audio" being set on a page automatically).
Create Form Edit tab for appropriate users.
delete Audio, etc. (cf. Property:Property_name)
- this page has a broken title: 2532_Gigs
- Mark priority projects
- Fix links to licenses
Export all entries in XML format.
- Create cron job to do this
- Create cron job to update CSV output page of GNU all projects
- Update the queries on GNU/Export to make sure the second column is the GNU package name property
- Update each GNU project with the GNU package name
- We can use the autoedit links for things like allow admins to do things like confirm that they have reviewed an entry or as a way for "voting-up" etc. Or any number of things. See autoedit section at bottom of Semantic Forms page.
proprietary program search
When a person searches for a proprietary program, a list of free software replacements for that program should appear in the search results, *however*, the proprietary program and its name should not appear anywhere on the wiki. To achieve this functionality, we may want to use the Enhanced Retrieval extension.
When doing license verification, we need to ensure two things:
- More than one person checks a license
- We have a system in place for training volunteers (via some sort of mentorship) on how to properly check a project's license.
Point system and mentoring
Some ideas we have discussed is that we might have some sort of scoring system, so that more experienced individuals who check a license have more "points" than people less experienced. Let's say we have three tiers: level-1, level-2, level-3; with level-1 being the most experienced. A check by a level-1 person might be worth 15 points, a level-2 might be worth 10 points, and a check by a level-3 person might be worth 5 points. It might be that a license is properly "checked" if it has a score of at least 25 points. To coordinate this work we might consider using an extension such as Semantic Tasks.
But, more important than the point system is ensuring that level-3 individuals are not only verified by level-1 individuals, but, that some 1-on-1 guidance and help/mentoring is provided to level-3 individuals from level-1 individuals.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the page “GNU Free Documentation License”.
The copyright and license notices on this page only apply to the text on this page. Any software or copyright-licenses or other similar notices described in this text has its own copyright notice and license, which can usually be found in the distribution or license text itself.