[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Overview, roadmap, priorities



Hello,

On Wed, 2 Aug 2000, Ben Armstrong wrote:

-->Date: Wed, 2 Aug 2000 01:33:44 +0000 (GMT)
-->From: Ben Armstrong <synrg@sanctuary.nslug.ns.ca>
-->To: jwaddell@ix.netcom.com
-->Subject: Re: Overview, roadmap, priorities
-->
-->This only went back to me ... did you intend to only address me
-->personally, or the Debian-Jr project as a whole?  at least one point
-->below should go back to the list.  Feel free to send this response
-->as is, or edited to the list.

whole list.

-->
-->On Thu, 20 Jul 2000, Kidsgames Project Coordinator - Jeff Waddell wrote:
-->> -->There are, of course, the goals you have already seen at:
-->> -->
-->> -->	http://www.debian.org/devel/debian-jr
-->> -->
-->> -->Re-reading those, does that spark any ideas?
-->> -->
-->> 
-->> Yeah, why is there only 1 thing in the education menu on debian (quiz)?
-->
-->good question :)  and one which might be more productive if directed
-->at the debian-jr list.
-->

redirected.

-->> -->1. dict
-->> -->
-->> 
-->> hmmm, need to find a way to use that for clare.  Her reading is going
-->> crazy now and she's always asking me to spell things for her when she
-->> writes notes.... She is set up with X and WindowMaker (her own theme that
-->> she made by combining two other themes...).  I have her automatically
-->> running pdmenu when she logs into an xterm (or if by chance she goes in
-->> text mode, which is very rare).  I'll have to incorporate dict into one of
-->> her menus.  Just set up dict as a menu item for her and had here test it a
-->> bit.  Looks like it works :)
-->
-->also, check out wordnet.  i'm just looking it over now, and it's great!
-->

6.8 M download, it'll be awhile before I tell it to get it.

-->> -->2. boggle (from bsdgames) 
-->> --> 
-->> Several of the nieces and nephews 9 - 13 enjoy this one.
-->> 
-->> -->3. hangman (also from bsdgames)
-->> -->
-->> Yep even made a special spelling word list for when she was practising for
-->> a spelling bee a few month's ago.  I find it doesn't really help with
-->> spelling though.
-->
-->heh.  well, i think more importantly it encourages pattern-matching skills
-->

yeah, it just isn't a match for the particular need if you see what I'm
referring to.

-->> -->There are special "video game" turns throughout the week which are limited
-->> -->in length.  We are increasingly uncomfortable with the legal issues
-->> -->surrounding the non-free games our kids like, and would like to see those
-->> -->be replaced with free ("guilt-free" :) alternatives. 
-->> -->
-->> 
-->> which non-free games are you referring to?  On or off the debian system?
-->
-->xmame games.
-->

hmmm, I play with emulators (including wine, vice, etc).  however I've not
turned my kids completely loose [1] on ANY emulated game or application
yet.  The emulation either isn't sufficient to the app, or there are not
suitable apps [that I have found, having not looked a whole lot] to run in
the emulator.

-->> Clare is looking forward to having her own desktop computer soon.  Not
-->> sure what I'll throw together for her, but it looks like it'll have to be
-->> soon.
-->
-->i guess it depends on what she's going to use it for, and if she's going
-->to continue to use your system as well.

This is trying to be determined.  I think it will have to be graphical, as
she is not completely comfortable even in the pdmenu stuff.  She likes all
the pretty stuff.  And really since we are testing LOTS of graphical
software she needs at least an X capable (probably just a terminal, using
xdmcp) computer.

-->  a 486 can be quite adequate as
-->long as the "video intensive" stuff continues to be done on the more
-->powerful systems in the house.  although a pentium or better is ideal.
-->

With the proper amount of ram and a decent video card yes.  Not sure about
audio yet (i.e. do I have her box have her one and somehow pipe the music
to that box when she's logged in via xdm or leave sound just on the main
box and have it piped to the centralized speaker's].  I think I have to go
with sound on her box, if for nothing else to use voicecontrol (let's you
launch applications with a voice command)

-->> The priority is to package as much of what is out there as possible as
-->> quickly as possible, once people realize there are *things* they can use
-->> already there, they'll be more inclined to join the party.
-->
-->i'm inclined to agree.

So get started ;)

-->  this discussion started out with "let's develop
-->a roadmap".

Thater way --->

-->  i have always thought "packaging" topped the list.  i guess
-->the question is ... since there is so much to package out there, "package
-->what"?

Whatever you can and have a desire to see in the project to start with.

-->  i'd rather not see the group's energy dissipated into packaging
-->things that are less relevant.

Each of us decides it is relevant by moving the process to package 
it forward.

-->  if we're going to package stuff, i guess
-->we should each choose our own corner of the heap to work on, and then try
-->to prioritize things according to what we thing is most important.

I can as yet claim no corner, besides we live on a round planet... :)

-->  and
-->i'm sure that's going to mean different things for different maintainers.
-->but at least in general we can say: yeah, video games are good, but let's
-->fill in the holes.  so i'm hearing from you that one hole is "education"
-->(is that just a hole in the menu system or in Debian in general?)
-->

The HOLE is in the OSS/Free Software Communities.  If it wasn't the
KidsGames project would NOT EXIST.

-->> -->I've tried a bit of tweaking of the menu system myself, and I just wasn't
-->> -->satisfied with the amount of hand-massaging was required.
-->> -->
-->> 
-->> Yeah, i'm hand tweaking the menu system as well and while I've modularized
-->> in each user's home directory it would be nice to have tool to do it for
-->> me.  a menu builder app would be GREAT.
-->
-->OK, Andreas asked about this on -devel, but got absolutely *zero*
-->response.  I hope he just caught them at a bad time, and that we can
-->attract some attention because, as I said, it's a broader problem than
-->just Debian-Jr.
-->

wishlist bug to pdmenu/whatever package builds the automatic debian menus.

-->> -->Just so we don't get off on a tangent on that one, I'm not sure that
-->> -->narrowing down options is such a big priority.  After all, it seems to be
-->> -->a bit contrary to "exploring worlds" that I mentioned earlier.
-->> -->
-->> 
-->> It's not about narrowing down options, it's about providing ACCESS to the
-->> worlds they need to explore.... Clare's typing skills as a 6 year are not
-->> *anything* like what your see in ten year olds.  She's just not there yet.
-->> Expecting her to type arcane syntax to a program name AS WELL AS the stuff
-->> she's trying to find out about is really not workable for her (it will be
-->> later, but it's not NOW).  So my challenge is to still make those things
-->> that will help here explore accessible.
-->
-->Good point.  OK, so I'm convinced that it's not a totally off-the-wall
-->idea.  Just wanted to make sure, as I'm sure that doing stuff with the
-->menu system is not going to be trivial, since it will involve a bunch of
-->grunt-work keeping Debian Jr's subset up-to-date with what is provided
-->in the standard menus.
-->

Why are you sure it's non-trivial?  Let's get the opinions of those that
really know the system like Joey Hess (pdmenu author) and whoever wrote
the automatic stuff.  The grunt work goes into the menu file in
<package-name>/debian/ when packaging as long as it matches with whatever
guidelines needs to be handled for the automatic menuing system.  We don't
need to do customizations of that automatic stuff if we build it into our
packages well.  Also there maybe spec/code/testing work for the menu
customization tool that allows us to make user specific menus as admin
instead of requiring the user's to do it themselves (although some of the
user's may also find a tool useful).  I think if gpanel could be made into
a console application things would be much easier in this reguard.  Maybe
take the ctk libary stuff that stormix has done and use it to make a
cpanel?

-->> -->Well, I'd better stop rambling and let some others throw their ideas in.
-->> -->Where do we start?
-->> 
-->> Application Packaging and thinking about the task packaging.
-->
-->Can't argue with this.
-->
-->> -->  What are our top priorities?
-->> 
-->> Off the top of my head 
-->> 
-->> gnomekiss (I have a working [not production just personal use] .deb of
-->> this and no I'm not a debian maintainer/developer... not even in the [very
-->> long] queue)
-->> gtans
-->> xjig
-->> tuxtyping
-->> tuxkart
-->> tuxAQFH
-->> gcompris (also have working .deb here)
-->> stickers
-->
-->haven't seen any of the above except stickers (which is great, btw!) ... 
-->can you give a brief description and/or URL for each?
-->

linuxforkids.com

-->> linux letters and numbers (lln)
-->
-->lletters is already packaged, but the package probably isn't up-to-date,
-->and is possibly even orphaned
-->

I believe I have a bug against it to have it upgraded (I believe Lalo
Martins is the maintainer).  He's on kidsgames with us I think, so
hopefully it (and others will move forward)...

-->> -->  What packages should be
-->> -->tackled first?
-->> -->
-->> 
-->> Probably a working theory on the task situation would be good.
-->
-->you mean task-* packages?  hm, not sure.

me either, somebody needs to research it, and My researching is in other
directions at the moment.  I know there's supposed to be a nifty new way
of doing task packages soon (package pools) but I don't know when or how
it works.

--> i had a notion that dividing
-->groups of packages along two axes would work ... first, a few rough age
-->categories (preschool, grade-school, high-school, all-ages) and then
-->perhaps some topical categories (video-games, word-games, file-managers,
-->educational, reference, ...)  But all of the possible permutations of just
-->these few off the top of my head gives us a staggering number of task-*
-->packages.  perhaps this is the wrong approach?
-->

Start with 

task-debian-jr

?

hmmm, i think i might prefer task-edu or something, but oh well.

Split it when we have enough packages to warrant?  Is that
resonable?

Don't they normally do that when packages get to big or unwieldy?

-->Ben
-->

Gotta sleep soon....
-- 
Jeff Waddell
jeff@smluc.org

Kids Games Project Coordinator
main website at http://smluc.org/SIA/kidsgames/



Reply to: