Re: Sv: Synopsis

[JF Martinez <jfm2@club-internet.fr>]

> 
> Jean:
> 
> > Translations both of software descriptions and	!
> > of some texts seen by the user during install	! None
> 
> I'm willing to give this a shot. I (still) can't find the time to update
> the web pages, but this task should be easier to handle (when talking in
> time-related terms, of course :)
> 

There are two things: the one is getting the SPEC file of an SRPM and 
duplicate the descrption fields like this:

%description:
The Pi poem allows to know the 30 first digits of number Pi

%description(fr):
Le Poème de PI permet de connaitre les 30 premiers chiffres de Pi

Then the RPM needs to be rebuilt but that needs that the people doing
it have same versions of libraries (or be the same person)

The other one is ensuring that the texts seen at install time by the
danish user match those seen by the english speaking user.  The
English text is not the RedHat text with RedHat replaced by Indy since
it mentions things like phone support the provide and we cannot
provide.  There are laws against people who promise something to
customers and then fail to provide it so that means that I will have
to remove support for untranslated languages in order to remain within
the law.


> > Managing, taking care of those who fill the form! None
> 
> Explain the exact job description and I'll consider that one too.
> 

Mangaing means general coordination a thing I am truly lousy at

About taking care of the people who fill the form in the website: this
form is ambiguous since it does not make clear that people filling the
form are supposed to have the intention of taking part in development.
I suspect many of those who filled the form thought they were just
subscribing to the mail list.  That means I contacted them, lost time
explaining them what was Indy and then got disapointed when they
didn't contribute.

So first thing would be to change this page in a way the user can use
it for subscribing to the list but also the "recruiter" gets a mail
with the user data (name, mail and abilities) if the user has clicked
a button indicating that he is willing to participate and wants to be
contacted.

But the job is about negotiating with those people who told they were
willing to do something for Indy.

> > PR: ensuring that Indy's goals are widely known ! None
> 
> Do we have any posters etc. to use at shows, Linux meetings and "all those
> other events" that might come up?
> 

No.  They have to be designed.

> <OFF_TOPIC>
> 
> What is the official opinion on application performance (e.g. would an
> application written in C rate higher than a shell script just because it's
> a bit faster?)
> 

My opinion (but I want Indy being a team so it is my opinion not
Indy's official) is that it depends: I don't see much usefulness into
writing in C an application whose Perl or Python version takes just
one second.  I would consider rewriting if the Python version
needs hours, or if it is supposed to be interactive but time elapsed
between two succesive screens is unbearable.

A different thing is about optimizing hardware's use.  Since we expect
people using Linux for _real_ work, not as just a training tool that
means we cannot rely on the user having nothing better to do that
reading 3 thousand pages books containing all the Linux HOWTOs.  If a
feature makes the box faster then providing it out of the box is not
an option but a duty.  If we can provide a kernel who is only 1% worse
than one compiled by the user then a 10% slower kernel is not
acceptable.  If there is a way we could detect the user has a chipset
supporting UDMA 66 then let it in UDMA 33 is not acceptable.  If we
can make his video card two times faster then let it in default mode
is not acceptable.  Of course the above does not apply if the feature
is dangerous and we are unable to detect when it is safe to use it.


> </OFF_TOPIC>
> 

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org