2008/3/3, Alan Lord <[EMAIL PROTECTED]>: > * PM (This is very a technical issue and an emotive one, probably one of > the most important too as it may affect everything that follows in LFS-NG)
I am very surprised the nobody replied to my mail with the subject "RPM: proof of concept". > * Presentation (How we deliver/provide LFS-NG to the community, e.g. > Book, Dynamic web based, LMS, local machine-based application? More than > one?) I think that a "local machine-based application" option is the worst of them all. Reason: it is the least reliable, and the only one that doesn't allow easy changes of the presentation. For me, LFS must stay as "data" from the user's viewpoint, not "data+program", because bugs in the program will prevent the use of the data, and the reader is supposed to be able to discard or fix wrong data, but not fix errors in a program. Think about the recently reported jhalfs breakage in French locales as an example. No program, no bugs in it. > * Structure (The modular courseware approach, or something else?) This can only be defined after deciding about the target audience(s). > Perhaps some simple poll or voting system on the Wiki for areas of > contention be set-up and some basic rules about voting decided before we > start? (Having been closely following the MSOOXML fiasco, let's not look > like ISO please?) IMHO, voting should be used only as a last-resort method to come to an agreement, because the minority's opinion is completely ignored. Polls, on the other hand, are a good method to throw away options that nobody likes. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
