On Thu, 5 Mar 2009, Samuel Thibault wrote:
>> $ apt-cache search accessibility
>>
>> which is quite weak.
>
> Tags FTW. Look for Accessibility tags and you'll find a lot of
> packages.
Sure. But do all our package handling tool support DebTags?
Are our users aware of DebTags. (Well I admit they might fail
to find metapackages as well.) So I'd regard DebTags as a very
important technique and joining DebTags information with Blends
techniques is quite high on my todo list.
>> Thinks of alternatives like
>>
>>
http://blends.alioth.debian.org/science/tasks/>>
http://blends.alioth.debian.org/science/bugs/>
> Let me point out something which I think is important (even if I think
> that's not what you meant): accessibility is not a task. It's like i18n,
> it's orthogonal to tasks: for all the tasks above you actually need
> accessibility support.
I perfectly got this information out of your last mail. But IMHO this
is rather a question of terminology. I'd try to find out what might be
helpful for users and IMHO the Blends technique is quite useful. Feel
free to suggest a better terminus than task which fits all needs.
> I do not mean that the tool itself shouldn't be used of course.
Fine. ;-)
> The admin, no, but you (the disabled person) do know and just ask your
> friend/coworker to run e.g. orca (already installed by default). With
> USB braille devices, it would even be possible to automatically start
> it, no even need to sudo.
That's fine for this specific case. But my idea is that it is easier
to ask for not by default installed packages on the phone line to your
local admin if you have to ask for a single metapackage rather than a
list of packages. While I share your point that a default machine should
have all needed accessibility features there might be a list of "suggested"
packages or even new packages. In the later case would an apt-get update
be sufficient to include new software if the metapackage was properly
adjusted and net even a phone call would be needed.
>> The idea to iron out this knowledge inside the tasks files to enable
>> admins who have not enough specific knowledge about the needs of their
>> users is one means to help in this issue.
>
> Yes, we definitely need to have some sort of database that allows people
> to know the name of the tools they can try to use to help them anyway.
Fine. That's what I'm talking about.
>> So IMHO it makes sense to have a accessibility-gnome /
>> accessibility-kde (perhaps accessibility-desktop) metapackages which
>> are part of a default installation.
>
> Which can Depend/Recommend/Suggest depending on the criticity of the
> help provided by various packages:
> - can't use the computer without it (e.g. screen reader for blind people).
> - hard for me to use the computer without it (e.g. color scheme).
> - makes me more efficient (e.g. dasher).
Yes, that's the idea.
>> The advantage of using accessibility-gnome / accessibility-kde
>> metapackages is that you can perfectly handle the dependencies inside
>> the accessibility project because there will be no need to change d-i
>> or the Gnome / KDE tasks.
>
> Yes, I also think that'd be better.
>
>> IMHO yes - but in the way I suggested above and not by using explicite
>> package names.
>
> Sure. We don't want to have to bother d-i each time new accessibility
> packages get added :)
Fine.
If you want to follow this idea I'd suggest the following things:
0. Try to convince listmaster to fix bug #514023 and subscribe the
resulting mailing list debian-blends. I see a big need to have
at least one member of the accessibility team lurking on the
Blends list to make sure that we do not trap into the pitfalls
of choosing narrow minded names (like tasks) or just do other
things which are contra productive for your goal.
1. I used your nice classification page [1] to create the stuff
you need to create tasks and bugs pages which are linked here:
http://blends.alioth.debian.org/accessibility/ You can adjust the informatio in the related SVN
svn://svn.debian.org/wsvn/blends/projects/accessibility/trunk/debian-accessibility/tasks
Please read my comments and fix the info there!
I can add you to the blends team or you can send me a patch.
BTW, thanks to your fine software categorisation page the
creation of the tasks files took me about 15 minutes. IMHO
the result of the tasks and bugs pages is worth this effort.
2. Try to investigate whether something is wrong with your packages.
a)
http://blends.alioth.debian.org/accessibility/tasks/console.html says that these packages do not have a homepage. This is possibly
not true but the control file of the package is lacking the
Homepage field. If you fix the package control information
the tasks page will be fixed after the next cron job run
(twice a day).
b) Consider group maintenance in a common repository - it has
turned out a good means to fix things like missing Homepage
fields, outdated policy versions etc.
c) Fix translations of package descriptions!
You might have noticed that some of the descriptions are
translated. IMHO this is *very* important. Just use the
links for tranlsation or fix translation to get quick
access to the DDTP server.
3. Ask questions if something remains unclear.
BTW, you have a broken link to GNOME Accessibility Project on [1]
The page
http://developer.gnome.org/projects/gap/ does not seem to exist.
Kind regards
Andreas.
[1]
http://www.debian.org/devel/debian-accessibility/software.en.html--
http://fam-tille.de--
To UNSUBSCRIBE, email to
debian-custom-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact
listmaster@...
