Here's some ideas I've thrown together. Nothing well worked out. Just some things I hope will put spark someone's interest enough to start another project.
Please note that when I recommend a single way to do something, I recognize that some variety may be better in many cases to promote competition in ideas. In some cases, there is no real need for competition; we just need to make an agreement on how to do something and move on. In other case, a few competetors would be welcome to encourage progress.
Along similar lines, please know that I do not intend to hurt feelings by my critisisms of other's choices. (I have little moral ground to stand on, having made no contributions of code to the community.) I only intend to influence future choices toward what I hope will be a better Linux environment.
I would like to see non-commercial software effort go mostly into the basic OS, utilities, and basic applications like system administration tools. Having free (even if mostly crude) applications may encourage people to jump on the Linux bandwagon, but they will jump off again if they can't easily administer their system.
Problem 1: People don't report bugs because they think it takes too long. Reporting a bug requires finding the bug reporting method, gathering configuration information, etc. The result is that bugs remain in the software longer and affect more people, giving Open Software a bad name.
Improvement: Make bug reporting easier.
Method: Create and maintain a web site for bug reporting. There are many options here. It could use HTML forms, but this would be inefficient for the bug reporters. It could provide e-mail addresses for every registered program for submitting bug reports. A bug report template could be made available. Better yet a program could be provided that would create a standard bug report with as much configuration information as it could figure out (possibly from a user's default template) already filled in. The program could read an on-line updateable file to get the bug reporting e-mail address from a buggy program's name entered by the user. (A method to handle two programs with the same name would be needed.)
Problem 2: People don't report bugs because they have little reason to believe that the bug report will be responded to.
Improvement: Provide feedback to bug reporters and to potential bug reports on the use of bug reports.
Method: I've no definite ideas here. Maybe find a volunteer to host a branch of that bug-reporting web site where developers can post each month or two the number of bug reports received an some comments on their current capability to act on them and why some were not acted upon.
Problem 3: People do not volunteer for projects because they do not get a good feeling that their efforts would be important. There is such cacaphony and anarchy in the developer's world and there is obviously a very lot of work that is wasted because of duplication of effort and wither-on-the-vine projects. This does not engender enthussiasm in Potential volunteers.
Improvement: Encourage and publicize the organization of "Linux improvement" and volunteer efforts.
Method 1: This is a tuff one. Find a volunteer to create and maintain a web site which documents the organization of the "Linux improvement" effort. It would lay out many of the important projects that use or need volunteers. (To lay out the entire effort would be an impossibly huge task.) Include lists of the volunteers for each project. Maybe allow the project leaders to include estimates of the percentage of the project contributed by each and some estimates of how many hours have gone into the project total and per month.
Method 2: A variation on Method 1. Create a single web site to which Linux projects would submit pages introducing their project and incouraging volunteers. The site would also try to inticate to readers where efforts are most needed to further the goal of making Linux easier to use and administer.
Problem 4: Beginners have much difficulty setting up multi-OS booting during Linux installation.
Improvement: Make the booting of Linux easier for beginners.
Method: Encourage beginners who choose to use other OSes on the same system to not use LILO. Instruct them how to create boot disks (and update them with rebuilt kernels) and use them to boot to Linux, bypassing the other OSes boot loader. Tell them they should learn how to use LILO later when the children can't hear them.
Problem 6: Windows that scroll don't scroll smoothy enough to read text while in motion.
Improvement: Give Linux an advantage over other OSes by allowing applications to scroll smoothly and change many existing applications and libraries to do this.
Method: Unknown. Probably requires a fix to the X server and/or to GUI libraries.
Problem 7: There's not enough window managers to choose from.
Improvement: Design and create another one.
Method:
The left inch or so inch of the screen gets covered
by a tall box that may be filled with the bulleted items as desired.
This leaves almost all of the screen for large full-height emacs, browser, and other
application windows in which people spend almost all of their time. Note: "selector"
here means an icon, button, menu item, or other sensitive screen area.
Problem 8: Many "man" manual pages state that they are obsolete.
Improvement: Develop a standard help system with user interfaces for standard terminals, GUIs, and Emacsen.
Method: Scheme should allow source material in several formats. It should use a few-day caching schem for reformatted files. Probably need to allow two versions, with and without graphics. Much more tbd. The "desktop" projects have their approaches to this problem. Are they considering common source material formats?
Problem 9: Common lpr/printer setups don't use a single spool for each printer which makes printer control unnecessarily awkward. For instance, printing order cannot be well controlled.
Improvement: Develop a lpr/printer setup that uses a single spool for each printer,
Method: Use a special spool which holds jobs while they are being prepared for printing. This spool allows a configurable number of jobs to be processed (mostly by ghostscript in practice) concurrently to control processor usage. It should also have a priority system to allow small jobs to finish before large ones or whatever is desired. Programs would submit their jobs to a "print" command rather than "lpr". The print program (script?) would have its own set of command options. One would enable "magic" file type determination or allow specification of the file type. A menu-driven config scheme could also be developed.
Problem #11: Certain peripherals (eg, tape drives) must be powered up at boot up, or they can never be recognized. (True even when using modules?) This is inconvenient.
Improvement: Allow seldom-used (and other) peripherals to be left off during boot.
Method: Unknown changes to kernel and device drivers.
Problem #10: Most software cannot be downloaded with assurance that it is the same as that released by it's stated maintainer.
Improvement 1: Develop and document methods and support tools to make authorization automatic or very easy.
Improvement 2: Develop a project which works with SW developers to convince and help them to participate in authorization schemes.
Problem #11:
Improvement:
Method:
Problem #12:
Improvement:
Method: