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/ /\ <pascal.bleser@skynet.be> <guru@unixtech.be> __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.