My resignation

Nathan Coulson conathan at conet.dyndns.org
Tue Jul 13 20:46:17 PDT 2004


> Ian Molton wrote:
>> On Tue, 13 Jul 2004 22:38:38 +0100
>> Matthew Burgess <matthew at linuxfromscratch.org> wrote:
>>
>>
>>>I don't have anything against IRC at all.  It is very useful for
>>>certain things (quickly hacking on things, proof-of-concept type
>>>stuff, discussions regarding build problems, etc.).  But, as has been
>>>mentioned in this thread several times it is *not* the place for me to
>>>be making decisions regarding things to be included/excluded from the
>>>book.
>>
>>
>> I agree. IRC moves *far* too fast for anything but unstable and covers
>> too few people to be representative.
>
> Sure irc moves fast be-lfs was done useing irc as the communication
> medium. But then again, targets were made and achived then revised and
> achived, Much like a meeting for a company/board of directors.
> Learn from buistness.
>
> It might be worth all the developers getting together and setting the
> targets for the book, in a meeting format with an agenda so that each
> issue can be covered on the spot. Even electing a chairman from the pool
> of developers. IMO the mailing lists arnt apropriate for this.
>
> Instead what LFS has no, is a bunch of people attempting to debate each
> little subject, A lot of which are never resolved untill a developer
> gets pissed off and impliments his own way. OR a way he quickly
> discussed with a small number of people. (irc/phone/aim/icq/whatever)
> Then this leads to people flameing irc as its the other Offical
> communication medium, used for support mainly.
>
> Eventually, a developer who has taken a lot of crap from so many people,
> leaves or at least considers it, much like the following....
> Jim, Zack, Alexander, Jeremy, Richard, Greg, timothy, Jesse the list
> goes on and on.
>
> Others move under the radar, And do vertually nothing, For fear some
> idiot is going to move against them, and flame any little changes they
> make. Slowing the overall progress. Instead of asking how it works, And
> what it fixes, Or whatever.
>
> In any case, some clear buistness practices need to be applyed to
> complicated projects, Clear definitions of jobs. Clear placement in the
> project. None of this shared placement, unless a person is going to be
> away, or unavalible.
> If a person is away or unavlible, there team leader steps up, Then if
> there team leader needs to confer with the other developers it is steped
> up to the mailing list or brought up at a meeting.
>
> For those who want a summery.
> 1. Clearly defined goals
> 2. Structure the developers (groups, team leaders, targets)
> 3. Define each developers specific job.
> 4. Have regular meetings. (for goal)
> 5. Name a Chairman for overall control (Answers to Gerard etc passes on
> mission statements etc etc etc)
> 6. Make an Offical Agenda for the meetings.
>
> -Zeplin
> --

It would be nice to gather a knowledge base of what individuals whom are
part of the community are familiar with,  (aka, in the "distant" future, I
believe it would be a good idea to reorganize the bootscripts following a
initramfs, and It would help if I knew who to talk to, and I also wanted
to look more into integrating event driven bootscripts as suggested by Ian
[hotplug/udev, appear to have .d directories in /etc for this purpose]).



More information about the lfs-dev mailing list