SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
@Harishankar: edited a rly small part of the slack's philo (PV still sells CD sets). Commented my changes.
I can't add something to the 'discussion' part of the article, so here it is: I read somewhere that PV's focus points for Slack is #1:stability, #2:security. Dunno how to put it, and it can be redundant to some of your already written points. But I know that's something I liked about Slack !
Originally Posted by kikinovak
I suggest the introduction of the word "soon". It adheres to the KISS principle and works in all timezones, both in UTC and localtime.
Wasn't talking about ETA, in fact, I just wanted to avoid several people writing the same article.
Now I have a question: I have spare time for the moment (looking 4 a job, just arrived in Sydney), so I may be able to integrate some parts of the Slackbook to teh wiki.
But I rly dunno where to start from, and particularly, where to put those articles ! Any thoughts/ideas ?
And somewhere in a post-installation section devoted to getting extra software, using sbopkg and src2pkg.
For instance, adding to sycamorex's scheme:
1.6 Switching from huge to generic kernel
2.1 Getting more software (links to Alien Bob's, rworkman's, ponce's,etc, repositories)
2.1.1 Use of sbopkg and src2pkg.
Really, I think we should have planned the overall structure before anything else. What/how many sections/pages to have, subsections, etc.
At the same time, if we all just stayed in the playground, we could create pages which could subsequently be moved into place/edited when the structure becomes apparent. For instance, if someone was working on importing the Slackbook, they should be able to use the sections given to get a general idea of how to split up the pages.
It seems to me that the best thing we can do with this early stage motivation is get content in the wiki. Afterwards, even if there is a drop-off of support, much of the work left to do can be accomplished rather easily by a handful of people. Once the pages are live, it will only require those few editors to approve changes to pages, as well as the occasional author to submit a new page. Of course there will be edits/updates needed, but that's why it's a wiki.
It would be a shame to dawdle in the beginning for lack of structure and lose documentation creation/copying efforts. At the same time, I think we should have a place where we can store the pages (playground?) while we wait for TOC, style and admin decisions to be made.
As for internationalization (heu, there's a reason they 18'd that), I think we should consider using the same approach (ie, simply uploading work to a 'sandbox' area, such as frlayground for french). Otherwise, I think it would be safe to say that translation of relevant sections of the Slackbook could be started already, as it seems we are going to be using that as a base. It seems only logical to involve people in the way that motivates them; if we can get someone who offers to translate the installation section into Deutsch, should we not let them? Note, they did not volunteer to copy/create documentation in English. If turned away, these people might simply not get involved.
I still feel it's easier to write down a structure than implementing it in a Wiki. Fleshing out the details and producing content will be the hardest part and having a head start on content is always nice. On the other hand, working with existing content, I feel that a Wiki is not a book, and shouldn't need to have strict adherence to a book-like structure with numbered sections.
The native Wiki concept of root nodes (or main subject matter), groups (with all related topics) and related pages (to interconnect topics that work together) work better in a Wiki. It is looser, and doesn't need ordering (except perhaps by alphabetical order in an Index or when specifically linked from the individual pages)
However, in deference to the views of others, I am not going to create any new pages until we have some consensus about this but I think everybody is in favour of a structure except me.
Of course it is easier but that's not the point. You don't start buying furniture until your house and rooms are ready.
You can still create articles in the playground area and then once the topic tree is ready you'll just paste them in the relevant sections.
I've just looked at Dokuwiki's way of managing structure and it looks fairly easy to me. The administrator with access to the wiki files on the server, simply moves the text files to appropriate sub folders in the data directory as necessitated by the "structure".
Bear in mind that that way you're creating additional work for somebody else. Easy or not, poor administrator if a lot of people start doing it. LOL