Slackware Documentation Project

zithro · 08-20-2012, 08:29 AM

@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 !

Quote:

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 ?

EDIT: ok, going to to the list

vharishankar · 08-20-2012, 08:29 AM

deleted.

brianL · 08-20-2012, 08:48 AM

Joined the mailing list and read the archive. While it's in its early stages, why not keep the planning discussion here on LQ?

vharishankar · 08-20-2012, 08:54 AM

deleted.

sycamorex · 08-20-2012, 09:00 AM

Quote:

Originally Posted by brianL

Really, I think we should have planned the overall structure before anything else. What/how many sections/pages to have, subsections, etc.

I think that's the key. I'm glad that everyone is willing to contribute but let's think it over and structure it first. Otherwise we'll end up with a total mess.

I was thinking about something like (for example):
It's incomplete, just an idea. I'm on lunch at work now so don't have time to think it through:

Code:

1. Slackware installation.
1.1 Methods
1.1.1. DVD/CD.....
1.1.2. Network....
...
...
1.3 Partitioning the drive
...
1.4. Adding a swap partition
1.5. Configuring users
...
...
...
1.7 Configuring networking 
1.7.2 Wireless networking 
1.7.3 Supported wifi adapters
      Broadcom 43.xxx configuration
      Atheros xxx configuration
      Using ndiswrapper
1.8.9

2. Post-installation tasks
2.1 ....
2.2 Optimising Slackware fonts (Dugan's stuff for example)
2.2...
2.3 KDE configuration and tweaks
2.4 Xfce configuration and tweaks

2.7 Configuring additional windows environments
2.7.1 Installing and configuring i3!!!!!:)


2.10. Terminals
2.10.1 configuring xterm (colours/etc)
2.11. Installing additional terminals
2.11.1 Configuring urxvt
..
..
...
..
..
..

3. Slackware as a server
3.1. Configuring NFS
3.2. Configuring a file server
..
...
...
4. Slackware multilib (Eric's stuff)
5. Games on Slackware
   Configuring wine
   5.1 Minecraft on Slackware
6. Staying -current

This is just a suggestion but once we've got a well thought over tree like that on one of the pages each person will easily be able to create a new article in the right place.

brianL · 08-20-2012, 09:05 AM

And somewhere in a post-installation section devoted to getting extra software, using sbopkg and src2pkg.
EDIT
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.

kikinovak · 08-20-2012, 09:12 AM

Quote:

Originally Posted by sycamorex

I think that's the key. I'm glad that everyone is willing to contribute but let's think it over and structure it first. Otherwise we'll end up with a total mess.

I was thinking about something like (for example):
It's incomplete, just an idea. I'm on lunch at work now so don't have time to think it through:

[code]1. Slackware installation.
1.1 Methods
1.1.1. DVD/CD.....
1.1.2. Network....
...
...
1.3 Partitioning the drive
...

That's EXACTLY what we need.

Now the Slackbook has a structure like this, already. I suggest just copying it over... and then modifying/adding as needed.

vharishankar · 08-20-2012, 09:14 AM

deleted.

rinias · 08-20-2012, 09:14 AM

Quote:

Originally Posted by brianL

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 fr

layground 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.

Simply put: you'd like to create? Great! Here's where you can put your information as it awaits editorial approval: http://taper.alienbase.nl/dokuwiki/playground

Riri

vharishankar · 08-20-2012, 09:25 AM

deleted.

brianL · 08-20-2012, 09:28 AM

Mmm, the more I think about it, the more I can see advantages to both sides: content first vs structure first.

sycamorex · 08-20-2012, 09:29 AM

Quote:

Originally Posted by vharishankar

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.

brianL · 08-20-2012, 09:37 AM

Quote:

Originally Posted by sycamorex

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.

Yeah. Sounds best. Less chance of mess and chaos.

vharishankar · 08-20-2012, 09:38 AM

deleted.

sycamorex · 08-20-2012, 09:44 AM

Quote:

Originally Posted by vharishankar

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