my notes at specific points with cuts to keep the size down
you may need martin's earlier message if you haven't followed this
At 08:57 PM 10/05/2006, you wrote:
Martin Schlander wrote:
> On Wednesday 10 May 2006 05:20, scsijon wrote:
>> Let us split our community away to handle tasks such as:-
>> a) assist with small useage \ new idea packages and
>> unexpected extension requirements to existing packages.
With "package", you really mean RPMs ?
Not primarily, preferably new programs that need assistance, such as
helping a designer to turn a program that is small market due to
designers initial limitations or initially only wanted for themself to
something that can spread, so definitely not just converting
existing rpm's between systems such as deb, rh, etc. although
that would be part of it
>> b) assist as we do now in "field" testing through the beta
>> program, but not only SuSE's but other packages that need larger
>> variations of testers.
That's a good idea. I'd sure like people to also test my packages (and
those in Packman) ;D
Though it is difficult to think about it now, it is highly dependent
on how 3rd party packagers will work with the build service or not.
Maybe all packages on Packman will be done through the build service,
maybe not. Well, all of them can't be managed in the build service,
because of legal reasons (mad, lame, mplayer, ...)
My original thoughts were along the lines of "to field test" anything we know
how to use currently against the new beta version's basic system and document
changes and differences with regard to expected outcome vs actual outcome.
I am slowly becoming of the opinion that there needs to be a Linus / ?W3
standard on how a source package shall be formed and made available.
>> c) assist as we do now in the problem fix process.
Could you elaborate a little what you mean with that ?
"Fix process" as in beta test phase or as general help to end-users,
i.e. web forums, suse-linux-e, suse-factory, IRC ?
report problems, and help in their duplication and fix as we do now
>> d) documentation, not only "how to use" types, but "using
>> this with these extensions this way allows you to do this" as well
>> as "this plus this plus this and either this or this but not including
>> this" makes a "qqqq" server. I, for example have decided to spend
>> my available time this year in creating a "Mini-Command Useage" Manual
>> that lists commands, what they are, their extensions plus a
>> number of standard used matrixes (such as ls -la) and what they give
>> you back. It will be able to be printed out as a mini-manual (a5/2 flip)
>> or a cardfile format for pda's etc. But I will say more on this
when I have
>> my thoughts in propper order and under an appropriate subject
>> header (of which this is not).
Right. I would dub this the "howto collection". I think that part is
very important, both for helping end-users but also for spreading SUSE
Linux.
how-to is only a small part, what I believe is needed is a "grow" manual
that allows you to start with the basics (eg the command only "ls"), add
the meanings and results of the generally used extensions (ls -l) and
provide the commonly used major commands (ls -Ralph). It would also have
the needed links to man, info, online refs etc. so as you become more
comfortable with what you are doing your able to expand.
Most of what was listed below, can be found already BUT in a format that needs
an expert level of knowledge, i'm more interested in something I could give to
any person with either a pre-installed system or the dvd that will COMPLETELY
create a basic system and work from there knowing the person will gain
confidence as she/he uses their inquisitiveness.
"High level" HOWTOs, e.g. (I mentioned them before, but they're rather
good examples IMHO):
cut
>> e) design and create the direction specifications of what we
>> think users will be wanting in the near future.
Could you elaborate ? I don't quite understand what you mean with this
one.
What will we dream?, wifi was a dream a few years ago, can we create an
active memory shrinker for packages so there is no waste memory space?,
lcd glasses that reflect images on the retina are in use by the various armed
forces today, why can't we do the same with the laptop and kill the screens?,
what about doing away with hard drives and use the memory stick memory?,
gloves instead of mice and keyboards (as you can do for joysticks and games),
do we have the capabilities if one became available at a decent price to make
use of it today?, and on I could go.. and i've only talked about hardware!
>> f) provide support to our communities across the world by
>> assisting with technical translation of ideas and "command formats"
Same as above ;)
any translator will tell you that the biggest problem in translating
is not converting
the "words" across, it's getting the "meaning of intent" or idea
across as it all
has to be in words so someone reading it raw understands exactly what is meant.
> g) marketing/promotion
Yep.
I actually see this as primarily a Novell Task, we should NOT be involved in
marketing.
Promotion on the other hand, we can assist with providing we are given the
tools and materials we need, WHEN we need them, not weeks later when
the direction has gone cold and lost.
> h) writing code/patches
As well.
In the same category: making packages ;)
this I consider part of (a) above
> I like this idea of splitting things up - but I think we need some kind of
We definitely have to categorize/split up those topics, which _could_
mean (just off the top of my head, maybe it's completely inadequate ;)):
- specific mailing-lists per topic
- specific "homepages" (or index, rather) on the wiki
- some kind of structure of teams
> formalized leadership/organization (call it what you want). I don't
Yes... "some kind of structure of teams" ;)
> necessarily believe in "leaders manifesting themselves
naturally". I think we
> need to form some kind of teams - with (elected) leads. And a
wikipage where
> you can see who are members of a certain team and how to join -
and what the
> tasks/responsibilities are, etc.
I don't believe the need of "leaders" is warranted, what would be
much more use
is mentors and guides, you don't want someone to take control of these teams,
you want someone who will keep them on direction and be able to write a spec.
Exactly. Topics, needed skills and interests are way different, which
means we have to somehow split/organize/structure them.
Splitting also means it's easier to structure and cope with goals,
tasks, people.
Of course, they're not totally independent and linking must happen
where appropriate. And some tasks involve several topics/teams.
> Of course everyone who's not in a team would be free to
contribute in any way
> he/she pleases.
Yes, obviously. The "team lead" (or whatever) is not there to decide
who may participate or not, it's there to coordinate tasks and
communication, and possibly, in extreme situations, take a decision if
no agreement can be found inside the team.
cheers
--
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
_\_v FOSDEM 2006 -- 25+26 February 2006 in Brussels
and that's my latest two bits
oh, and by the way, for those that want a return, payment for this
work should
be in kudos not financials.
scsijon
ps i'm in house move mode for the next four/five weeks (428km each way and
it's winter down here), i'll be online at least once a week but the
reply may not
return till the following.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
