Hi everyone!
I'm willing to join Linuxaudio Wiki updater team. I discussed this topic at #opensourcemusicians in IRC and I was told that here at forums are at least few maintainer-people. So what plans do you have for future development of the Wiki? Should I start updating Introduction-page or what?
I'd like to know some kind of long-term plan for Wiki development and then slowly implement it.
Is anyone related to the wiki or interested about it?
Linuxaudio Wiki maintainers?
Moderators: MattKingUSA, khz
-
Heikki Ketoharju
- Established Member
- Posts: 40
- Joined: Thu Mar 22, 2012 9:24 am
-
Heikki Ketoharju
- Established Member
- Posts: 40
- Joined: Thu Mar 22, 2012 9:24 am
Re: Linuxaudio Wiki maintainers?
Well, I started my work writing a new Introduction page from scratch. It's not live yet, because I'm waiting for some comments about it. Here: http://wiki.linuxaudio.org/wiki/new_introduction
I took skeleton to this page from Finnish Linux Audio guide article in Linux.fi wiki. Original article was written by me as well. Hope this is not too dramatic change. Also someone could check the facts.
I took skeleton to this page from Finnish Linux Audio guide article in Linux.fi wiki. Original article was written by me as well. Hope this is not too dramatic change. Also someone could check the facts.
Re: Linuxaudio Wiki maintainers?
A big improvement over the previous page. But since it's an intro page, I tried to simplify it even more.
Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.
-
Heikki Ketoharju
- Established Member
- Posts: 40
- Joined: Thu Mar 22, 2012 9:24 am
Re: Linuxaudio Wiki maintainers?
I personally think that this kind of short and accurate language is much better than language used in previous Introduction article. If others agree, I think same kind of work could be done on other parts of the wiki also. (Distributions page is this kind of page waiting for rewrite I think)
Could we start collecting and organizing articles around this New introduction page? How can other maintainers be reached?
Could we start collecting and organizing articles around this New introduction page? How can other maintainers be reached?
-
Heikki Ketoharju
- Established Member
- Posts: 40
- Joined: Thu Mar 22, 2012 9:24 am
Re: Linuxaudio Wiki maintainers?
I discussed with HisaoNakai on IRC and suggested we cound continue discussion about wiki here in this topic. So here comes few ideas about the wiki:
1) Why we need and introduction? Isn't start page enough?
I think wiki needs a short and accurate introduction/beginner article. I think target audience would be someone who knows few things about digital audio and has used other (non-free) platforms. Of course we can discuss if better target audience would be for example Linux users who know their system and would like to learn about music. I still think most of us have used propietary platforms, because that's what is teached in schools and used widely in studios. Hence the target audience selection.
In addition to the introduction / beginner article we need a good start page that has more than just collection of links. Many people come to the wiki searching something. Start page must tell them where to find it. It has to give good and clear information about contents of the wiki – at a glance. It took ages for me to realize that there are two (now three?) separate sections in the wiki: wiki and apps. This kind of things must be clear to the visitor from beginning.
2) Do we need a page called "community"?
The reason I added page called community is that there should really be one article that gives a clear overview about three or four most important support/discussion channels available. Currently wiki has four of them, and all are quite lengthy. I think we should write one "main" community article and then subsections to that, containing lengthy lists of blogs, regional forums in different languages, project-specific mailing lists and whatnot)
So why the name "community"? Well, If you check Ardour, Rosegarden, LMMS or Pure Data sites, they have information about IRC channels and forums in a page called community. Another quite popular form is support (Used by Linux Sampler for example). Most popular Linux distros call IRC/Forums/mailing lists to "community" or "support". So that's why I think it would be easier for people coming to linuxaudio wiki searching information about where the Linuxaudio community gathers, they could go to page called "Community" – not for example "places". "Support" is not suitable for Linuxaudio wiki, because in my opinion there isn't any particular "product" we could "support".
3) How wiki should be developed?
I think best wikis have many short or medium-length articles linked together. Currently there is quite a lot of duplicate information and long, little bit un-organized articles. We should make a plan how information should be re-organized and then implement it. That way we could have less toe-stepping and more actual progress
Some articles could be combined and some others maybe divided to several articles. We need a group of general rule-of-thumbs which could be used as a basis for decision-making.
4) technical / UI needs
I think the idea of dividing wiki to separate sections (/wiki, /apps, /hw) is good, but it needs better navigation UI. How could we build a clear and easy to use main navigation to the wiki? Currently it's hard for user to 1) tell where she is 2) move to different section 3) find a wiki start page.
Normally start page can be reached by clicking top-left image. That's the way how Wikipedia works, for example. But our wiki works different: clicking the image takes user to the start of the current section, not the main start page. Should we change this?
Another thing that makes wiki a little bit hard to use is table of contents section in articles. Text is quite small and links are near to each other. Can we change this easily?
1) Why we need and introduction? Isn't start page enough?
I think wiki needs a short and accurate introduction/beginner article. I think target audience would be someone who knows few things about digital audio and has used other (non-free) platforms. Of course we can discuss if better target audience would be for example Linux users who know their system and would like to learn about music. I still think most of us have used propietary platforms, because that's what is teached in schools and used widely in studios. Hence the target audience selection.
In addition to the introduction / beginner article we need a good start page that has more than just collection of links. Many people come to the wiki searching something. Start page must tell them where to find it. It has to give good and clear information about contents of the wiki – at a glance. It took ages for me to realize that there are two (now three?) separate sections in the wiki: wiki and apps. This kind of things must be clear to the visitor from beginning.
2) Do we need a page called "community"?
The reason I added page called community is that there should really be one article that gives a clear overview about three or four most important support/discussion channels available. Currently wiki has four of them, and all are quite lengthy. I think we should write one "main" community article and then subsections to that, containing lengthy lists of blogs, regional forums in different languages, project-specific mailing lists and whatnot)
So why the name "community"? Well, If you check Ardour, Rosegarden, LMMS or Pure Data sites, they have information about IRC channels and forums in a page called community. Another quite popular form is support (Used by Linux Sampler for example). Most popular Linux distros call IRC/Forums/mailing lists to "community" or "support". So that's why I think it would be easier for people coming to linuxaudio wiki searching information about where the Linuxaudio community gathers, they could go to page called "Community" – not for example "places". "Support" is not suitable for Linuxaudio wiki, because in my opinion there isn't any particular "product" we could "support".
3) How wiki should be developed?
I think best wikis have many short or medium-length articles linked together. Currently there is quite a lot of duplicate information and long, little bit un-organized articles. We should make a plan how information should be re-organized and then implement it. That way we could have less toe-stepping and more actual progress
Some articles could be combined and some others maybe divided to several articles. We need a group of general rule-of-thumbs which could be used as a basis for decision-making.
4) technical / UI needs
I think the idea of dividing wiki to separate sections (/wiki, /apps, /hw) is good, but it needs better navigation UI. How could we build a clear and easy to use main navigation to the wiki? Currently it's hard for user to 1) tell where she is 2) move to different section 3) find a wiki start page.
Normally start page can be reached by clicking top-left image. That's the way how Wikipedia works, for example. But our wiki works different: clicking the image takes user to the start of the current section, not the main start page. Should we change this?
Another thing that makes wiki a little bit hard to use is table of contents section in articles. Text is quite small and links are near to each other. Can we change this easily?
-
Heikki Ketoharju
- Established Member
- Posts: 40
- Joined: Thu Mar 22, 2012 9:24 am
Re: Linuxaudio Wiki maintainers?
Addition: I changed wiki a little bit. Mainly I edited apps/start page to link back to the main section: http://wiki.linuxaudio.org/apps/start
This is not ideal solution for navigation, but at least it's something... We really would benefit of clear navigation where three different parts of the wiki would be clearly visible.
This is not ideal solution for navigation, but at least it's something... We really would benefit of clear navigation where three different parts of the wiki would be clearly visible.
-
TheSafePlaces
- Established Member
- Posts: 200
- Joined: Sat Nov 26, 2011 8:50 am
Re: Linuxaudio Wiki maintainers?
Introduction page - I think thought needs to be given to whether you're introducing the wiki or Linux audio itself. The Arch wiki, for instance, has no page introducing the wiki - and even in our case, the /wiki/start page is introduction enough.
That said, a page introducing audio work on Linux is good, and a low-priority (i.e. to be done preferably after the rest of the wiki is more mature) 'history of this wiki' page would also be nice.
However - keep in mind that this is the wiki - not a beginner's guide. It is the exhaustive resource and archive of resources. People new to Linux or Linux audio are NOT supposed to be reading anything in /wiki/, they have to be pointed to the current best 'Linux audio for beginners' guide around, right at the /start page. The wiki is for detailed, not concise, information.
I say that Heikki's introduction should be kept, but rename it to 'An Introduction to Audio on Linux' (or something similar), put it under the Knowledge Base header on /start, and increase its detail level - in the future, it can also serve as a starting point to link to other articles.
Community page - I agree with the requirement, but there are better ways than making a new page containing information that already exists on other pages. Just mention the contact information on the /start page - simplicity itself.
Development - I have been advised this from many people over, and this is the current scope of the wiki as well - it should be a detailed resource, not a simple beginner's one.
Navigation - Yes, it is a problem. Ideally, IMHO - Have 3 icons on the left hand pane - wiki, apps, hw - and whichever one you're not on should be smaller. The root needs to look at this (rgareus is busy, I think. AutoStatic?). We also need someone to look at implementing better tag listing capabilities, see the 20/04/2014 (latest) post on http://wiki.linuxaudio.org/wiki/editors ... re_support
I think we need to clean up the existing stuff before adding new things.
No one should remove any external links without asking - just tag it as deprecated, instead. Internal resources can, on the other hand, safely be updated.
The method for posting external links is to make a page for that link, and tag it accordingly, see http://wiki.linuxaudio.org/apps/categor ... umentation for lots of examples.
If you need to make a new tag, ask first.
Developer docs are being worked on by AndreeeCZ, others wanting to help him may get in touch with him on IRC.
These pages are in need of attention (I put up those notes to indicate what needs work) -
http://wiki.linuxaudio.org/wiki/music_making_resources
http://wiki.linuxaudio.org/wiki/instruments
http://wiki.linuxaudio.org/wiki/free_audio_data
In the meantime, submissions for Hardware Database entries would be most appreciated by all members of the community. The sample page - http://wiki.linuxaudio.org/hw/behringer-bcd3000 - outlines the entry format. Proposals for changes to the format and rating system would be appreciated on http://wiki.linuxaudio.org/wiki/editors ... re_support
That said, a page introducing audio work on Linux is good, and a low-priority (i.e. to be done preferably after the rest of the wiki is more mature) 'history of this wiki' page would also be nice.
However - keep in mind that this is the wiki - not a beginner's guide. It is the exhaustive resource and archive of resources. People new to Linux or Linux audio are NOT supposed to be reading anything in /wiki/, they have to be pointed to the current best 'Linux audio for beginners' guide around, right at the /start page. The wiki is for detailed, not concise, information.
I say that Heikki's introduction should be kept, but rename it to 'An Introduction to Audio on Linux' (or something similar), put it under the Knowledge Base header on /start, and increase its detail level - in the future, it can also serve as a starting point to link to other articles.
Community page - I agree with the requirement, but there are better ways than making a new page containing information that already exists on other pages. Just mention the contact information on the /start page - simplicity itself.
Development - I have been advised this from many people over, and this is the current scope of the wiki as well - it should be a detailed resource, not a simple beginner's one.
Navigation - Yes, it is a problem. Ideally, IMHO - Have 3 icons on the left hand pane - wiki, apps, hw - and whichever one you're not on should be smaller. The root needs to look at this (rgareus is busy, I think. AutoStatic?). We also need someone to look at implementing better tag listing capabilities, see the 20/04/2014 (latest) post on http://wiki.linuxaudio.org/wiki/editors ... re_support
I think we need to clean up the existing stuff before adding new things.
No one should remove any external links without asking - just tag it as deprecated, instead. Internal resources can, on the other hand, safely be updated.
The method for posting external links is to make a page for that link, and tag it accordingly, see http://wiki.linuxaudio.org/apps/categor ... umentation for lots of examples.
If you need to make a new tag, ask first.
Developer docs are being worked on by AndreeeCZ, others wanting to help him may get in touch with him on IRC.
These pages are in need of attention (I put up those notes to indicate what needs work) -
http://wiki.linuxaudio.org/wiki/music_making_resources
http://wiki.linuxaudio.org/wiki/instruments
http://wiki.linuxaudio.org/wiki/free_audio_data
In the meantime, submissions for Hardware Database entries would be most appreciated by all members of the community. The sample page - http://wiki.linuxaudio.org/hw/behringer-bcd3000 - outlines the entry format. Proposals for changes to the format and rating system would be appreciated on http://wiki.linuxaudio.org/wiki/editors ... re_support
Looking for the ideal distro. NixOS?
Newbie composer, somewhat-experienced classical guitarist.
Largely known as HisaoNakai/contrapunctus on IRC and other places.
Newbie composer, somewhat-experienced classical guitarist.
Largely known as HisaoNakai/contrapunctus on IRC and other places.
Re: Linuxaudio Wiki maintainers?
Its great that you are both working on this.
I just want to cast my 2 bits in that indeed a wiki isn't a book (or at least our wiki isn't). It shouldn't be "navigated" per se. It is a resource, an encyclopedia. The way you get to a page is that you were searching for it or clicking a linked keyword from another article. Every article should be able to standalone as a complete work and only cover the topic mentioned in the title. It assumes you have knowledge of the terminology etc, because if you don't, you click that word and read the article on that. I use wikipedia nearly every day and I don't know if I've even seen the start page.
Sounds like the development is actually quite organized (tagging etc). I hope you guys continue to make progress. I know TheSafePlaces has been working a lot on it for some time, so I think its probably wise to follow his lead.
I just want to cast my 2 bits in that indeed a wiki isn't a book (or at least our wiki isn't). It shouldn't be "navigated" per se. It is a resource, an encyclopedia. The way you get to a page is that you were searching for it or clicking a linked keyword from another article. Every article should be able to standalone as a complete work and only cover the topic mentioned in the title. It assumes you have knowledge of the terminology etc, because if you don't, you click that word and read the article on that. I use wikipedia nearly every day and I don't know if I've even seen the start page.
Sounds like the development is actually quite organized (tagging etc). I hope you guys continue to make progress. I know TheSafePlaces has been working a lot on it for some time, so I think its probably wise to follow his lead.
_ssj71
music: https://soundcloud.com/ssj71
My plugins are Infamous! http://ssj71.github.io/infamousPlugins
I just want to get back to making music!
music: https://soundcloud.com/ssj71
My plugins are Infamous! http://ssj71.github.io/infamousPlugins
I just want to get back to making music!
-
Heikki Ketoharju
- Established Member
- Posts: 40
- Joined: Thu Mar 22, 2012 9:24 am
Re: Linuxaudio Wiki maintainers?
You and ssj71 may be right on this one. I don't want a separate introduction page for the wiki, but really an introduction page to Linux Audio as a whole, like you suggested. I think that we should review current /start page and see if links are grouped right way, but generally current situation is ok. Some image would cheer up the atmosphere, thoughTheSafePlaces wrote:Introduction page - I think thought needs to be given to whether you're introducing the wiki or Linux audio itself. The Arch wiki, for instance, has no page introducing the wiki - and even in our case, the /wiki/start page is introduction enough.
I find also longer and more beginner-friendly articles useful. Especially when there isn't any good beginner's guides to Linux audio. At least I don't know any.TheSafePlaces wrote: However - keep in mind that this is the wiki - not a beginner's guide. It is the exhaustive resource and archive of resources. People new to Linux or Linux audio are NOT supposed to be reading anything in /wiki/, they have to be pointed to the current best 'Linux audio for beginners' guide around, right at the /start page. The wiki is for detailed, not concise, information.
I totally agree. Let's do this!TheSafePlaces wrote: I say that Heikki's introduction should be kept, but rename it to 'An Introduction to Audio on Linux' (or something similar), put it under the Knowledge Base header on /start, and increase its detail level - in the future, it can also serve as a starting point to link to other articles.
This depends about what role we will give to start page. If it's just a collection of links, we need one single link to article that contains all the contact information. If it is more like a "short introduction to Linux audio community" then the information could be there. I think current situation is "links to contents of the wiki" and I'm ok with it.TheSafePlaces wrote: Community page - I agree with the requirement, but there are better ways than making a new page containing information that already exists on other pages. Just mention the contact information on the /start page - simplicity itself.
I agree. This needs more thought and developer workforce.TheSafePlaces wrote: Navigation - Yes, it is a problem. Ideally, IMHO - Have 3 icons on the left hand pane - wiki, apps, hw - and whichever one you're not on should be smaller. The root needs to look at this (rgareus is busy, I think. AutoStatic?). We also need someone to look at implementing better tag listing capabilities, see the 20/04/2014 (latest) post on http://wiki.linuxaudio.org/wiki/editors ... re_support
I think this tag system works very well with distros and hardware support, but I'm not so sure about external links. Tag system is qute heavy, and adding/removing/moving categories is a big decision. This system suits to situations where it's easy to divide things to categories, but I'm not sure if single external link is that kind of resource. Linked articles have many different forms, tones and topics.TheSafePlaces wrote: The method for posting external links is to make a page for that link, and tag it accordingly, see http://wiki.linuxaudio.org/apps/categor ... umentation for lots of examples.
If you need to make a new tag, ask first.
If we agree with this tagging method, there are still few little issues that would need to be solved. Currently all lists sort alphabetically, and sorting cannot be changed. I think some other sorting rule (link date?) would be more appropriate. We should update the look of lists also. Currently they are hard to read due to small line spacing and narrow lists.
Re: Linuxaudio Wiki maintainers?
Yeah, like broken links, I just clicked on the first 3 software titles on the "MIDI Software" page, and the websites for 2 of them ("ace" and "aconnectgui") no longer exist. I can't seem to edit the page to correct this stuff.clean up the existing stuff
I just went through the hardware page and fixed numerous broken links to product pages and images that have moved/vanished. (I also updated link text so that nearly all the audio interfaces are no longer listed as "General").
Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.
Re: Linuxaudio Wiki maintainers?
Here are the "MIDI Software" http://wiki.linuxaudio.org/apps/categor ... i_software titles whose project pages are 404. Links should be updated, or the title deleted if no longer available. I've done only upto "M" so far.
ace
aconnectgui
amidmap
elody
gmc
GMidiMon
improv
Input Maps
jack-keyboard
jMusic
JSynthLib
mcontrol
Melys
Midge
MIDI-Perl
midi2gmn
MidiChat
MidiComp
MidiMutator
midiplay/midirec
midirgui
MIDI Modules
Musica
pmidi
pyalsa
RawMIDI2SMF
Shake Tracker
Simple Sysexxer
srgplay
sxpress
SysExxer
UltiMusE-LX
UMP
xgmc
Additional edits:
aseqjoy - need better description on main page
aseqmm - renamed Drumstick, which already is listed
bcx2000edit - should link to website, not source code
BEAST - screenshot link broken
binars - dead project should be deleted
Bol Processor - need better description
cmt - should link to website, not source code
glib - Windows, not linux
IEEE P1639 - update link
kmid - renamed Drumstick Karaoke
libsmf - update link
Midithing - dead project
OplEdit - new link http://www.ugcs.caltech.edu/~john/compu ... ledit.html
playmidi - new link http://sourceforge.net/projects/playmidi
Q-Midi - dead project should be deleted
sc88sysex - need better description on main page
wildmidi - new link https://github.com/Mindwerks/wildmidi and new description
EDIT: Went through the remaining links. This page needs maintainence.
ace
aconnectgui
amidmap
elody
gmc
GMidiMon
improv
Input Maps
jack-keyboard
jMusic
JSynthLib
mcontrol
Melys
Midge
MIDI-Perl
midi2gmn
MidiChat
MidiComp
MidiMutator
midiplay/midirec
midirgui
MIDI Modules
Musica
pmidi
pyalsa
RawMIDI2SMF
Shake Tracker
Simple Sysexxer
srgplay
sxpress
SysExxer
UltiMusE-LX
UMP
xgmc
Additional edits:
aseqjoy - need better description on main page
aseqmm - renamed Drumstick, which already is listed
bcx2000edit - should link to website, not source code
BEAST - screenshot link broken
binars - dead project should be deleted
Bol Processor - need better description
cmt - should link to website, not source code
glib - Windows, not linux
IEEE P1639 - update link
kmid - renamed Drumstick Karaoke
libsmf - update link
Midithing - dead project
OplEdit - new link http://www.ugcs.caltech.edu/~john/compu ... ledit.html
playmidi - new link http://sourceforge.net/projects/playmidi
Q-Midi - dead project should be deleted
sc88sysex - need better description on main page
wildmidi - new link https://github.com/Mindwerks/wildmidi and new description
EDIT: Went through the remaining links. This page needs maintainence.
Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.
-
TheSafePlaces
- Established Member
- Posts: 200
- Joined: Sat Nov 26, 2011 8:50 am
Re: Linuxaudio Wiki maintainers?
ssj71 - My thoughts exactly, and thanks
Hey, j_e_f_f_g .
Perhaps I misunderstand what you mean, but - please do not delete or remove anything!
If something is outdated, tag it with 'unmaintained'.
If a link is broken and there is no new link for said project/content, tag it with 'dead_link'.
If you have deleted anything, please restore them from the older revisions.
Lastly, fixing hardware pages is, sadly, wasted and duplicated effort - because they'll all be deprecated as the hardware db is populated. The HW DB entries will use the information from them, after re-checking and, if necessary, correcting or updating. Rather than correcting them, just make HW DB entries (although, the proposal of having an actual database to host it puts things in a bit of a limbo). When all information from the hardware pages has been transferred to the equivalent HW DB entries, the hardware pages may safely be removed.
/apps/categories/documentation has a section called Online Articles. It is displayed using {{topic>on-line_articles}}
Some entries under the on-line_articles category are marked with the 'dead_link' tag.
To show all entries under on-line_articles but not the ones under dead_link, you can simply slap {{topic>on-line_articles -dead_link}} on a page. Ha!
This lets us keep super old stuff, even if it's just references to things that no longer exist, for archiving purposes...while still presenting new content to users who need it, in a low-maintenance and highly user-friendly manner.
But I digress - to show all entries from more than one categories - use {{topic>tag1 +tag2}} . To show all entries tagged with tag1 but not with tag2, use {{topic>tag1 -tag2}}
That makes it easy to categorize and recategorize anything, quickly and with far less work.
Other useful manipulations to {{topic>}} are mentioned here - https://www.dokuwiki.org/plugin:tag#topic
What I do miss is something that lets the user change this around, through a GUI based interface (checkboxes etc), in real time. That'd be more flexible, more useful, and would make better use of the tagging system. There also ought to be a tagging inheritance system - rgareus seemed to imply that there might be one. I'll speak to nido and AutoStatic about it.
I hope that helps with any queries about the tag system's aptitude.
Hey, j_e_f_f_g .
Perhaps I misunderstand what you mean, but - please do not delete or remove anything!
If something is outdated, tag it with 'unmaintained'.
If a link is broken and there is no new link for said project/content, tag it with 'dead_link'.
If you have deleted anything, please restore them from the older revisions.
Lastly, fixing hardware pages is, sadly, wasted and duplicated effort - because they'll all be deprecated as the hardware db is populated. The HW DB entries will use the information from them, after re-checking and, if necessary, correcting or updating. Rather than correcting them, just make HW DB entries (although, the proposal of having an actual database to host it puts things in a bit of a limbo). When all information from the hardware pages has been transferred to the equivalent HW DB entries, the hardware pages may safely be removed.
Agreed, and that's exactly why we should have tags! xD For instance -Heikki Ketoharju wrote:Linked articles have many different forms, tones and topics.
/apps/categories/documentation has a section called Online Articles. It is displayed using {{topic>on-line_articles}}
Some entries under the on-line_articles category are marked with the 'dead_link' tag.
To show all entries under on-line_articles but not the ones under dead_link, you can simply slap {{topic>on-line_articles -dead_link}} on a page. Ha!
This lets us keep super old stuff, even if it's just references to things that no longer exist, for archiving purposes...while still presenting new content to users who need it, in a low-maintenance and highly user-friendly manner.
But I digress - to show all entries from more than one categories - use {{topic>tag1 +tag2}} . To show all entries tagged with tag1 but not with tag2, use {{topic>tag1 -tag2}}
That makes it easy to categorize and recategorize anything, quickly and with far less work.
Other useful manipulations to {{topic>}} are mentioned here - https://www.dokuwiki.org/plugin:tag#topic
What I do miss is something that lets the user change this around, through a GUI based interface (checkboxes etc), in real time. That'd be more flexible, more useful, and would make better use of the tagging system. There also ought to be a tagging inheritance system - rgareus seemed to imply that there might be one. I'll speak to nido and AutoStatic about it.
I hope that helps with any queries about the tag system's aptitude.
Check wolftune and danboid's KXStudio Manual. I think it should be expanded to include a section on the other big distro (AVLinux), a central introduction, and should be moved to a distro-agnostic location, perhaps some linuxaudio.org subsection (or maybe the wiki itself, but I don't feel that's advisable). I intend to speak to danboid about it and do that, when the wiki is in a better state.Heikki Ketoharju wrote:I find also longer and more beginner-friendly articles useful. Especially when there isn't any good beginner's guides to Linux audio. At least I don't know any.
Looking for the ideal distro. NixOS?
Newbie composer, somewhat-experienced classical guitarist.
Largely known as HisaoNakai/contrapunctus on IRC and other places.
Newbie composer, somewhat-experienced classical guitarist.
Largely known as HisaoNakai/contrapunctus on IRC and other places.
Re: Linuxaudio Wiki maintainers?
Code: Select all
If a link is broken and there is no new link for said project/content, tag it with 'dead_link'.Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.
-
TheSafePlaces
- Established Member
- Posts: 200
- Joined: Sat Nov 26, 2011 8:50 am
Re: Linuxaudio Wiki maintainers?
j_e_f_f_g - I just illustrated, in my previous post, how those can immediately and effortlessly be removed from displaying unless the user chooses to display them (a regular page should exclude them while having a 'show deprecated' link which for now will have to lead to a new page which does not exclude them - I hope we have something one day which generates the page dynamically based on user input, allowing users to see content from more combinations of tags), while still being available in the archive. I think it's a good thing to have a reference to them, even if they no longer exist. If others disagree with me on this, then very well, feel free to remove them.
Edit - And even right now, the marked unmaintained/dead_link entries are pretty nicely visible thanks to those icons.
Future work -
I suggest we not edit /apps/categories/documentation for now. Accordingly, I've removed the sign from it.
Firstly, I notice that most if not all 'link-pages' listed on on /apps/categories/documentation are situated in /apps/ - we have to move anything that is not an entry for a software or distro, from /apps/ to /wiki/links/. Because of the tags system, it doesn't matter where the page is, it'll get listed - the lists on /apps/categories/documentation won't change even after the move. Maybe AutoStatic can move the pages from the shell - it'd be quicker, and save us all a lot of trouble - I've dropped him a 'memo' on IRC, let's see what he says first.
Then, let us mark any and every link which is of interest to _developers_ with a tag - for instance, 'dev'. This is also a good time to check and review if any link is dead or unmaintained, and tag it with 'dead_link' or 'unmaintained' accordingly.
After that, let us make two pages - /wiki/user_resources and /wiki/developer_resources . These will contain the links which are currently in /apps/all/ - essentially, all external resources of the wiki (predictably, User Resources and Developer Resources go under 'External resources' on /wiki/start). The 'dev' tag will help us list the content based on relevance.
Till we hear from AutoStatic, if anyone wants to improve the wiki's internal/local documentation, be it user or developer documentation, please feel free to do so.
Edit - And even right now, the marked unmaintained/dead_link entries are pretty nicely visible thanks to those icons.
Future work -
I suggest we not edit /apps/categories/documentation for now. Accordingly, I've removed the sign from it.
Firstly, I notice that most if not all 'link-pages' listed on on /apps/categories/documentation are situated in /apps/ - we have to move anything that is not an entry for a software or distro, from /apps/ to /wiki/links/. Because of the tags system, it doesn't matter where the page is, it'll get listed - the lists on /apps/categories/documentation won't change even after the move. Maybe AutoStatic can move the pages from the shell - it'd be quicker, and save us all a lot of trouble - I've dropped him a 'memo' on IRC, let's see what he says first.
Then, let us mark any and every link which is of interest to _developers_ with a tag - for instance, 'dev'. This is also a good time to check and review if any link is dead or unmaintained, and tag it with 'dead_link' or 'unmaintained' accordingly.
After that, let us make two pages - /wiki/user_resources and /wiki/developer_resources . These will contain the links which are currently in /apps/all/ - essentially, all external resources of the wiki (predictably, User Resources and Developer Resources go under 'External resources' on /wiki/start). The 'dev' tag will help us list the content based on relevance.
Till we hear from AutoStatic, if anyone wants to improve the wiki's internal/local documentation, be it user or developer documentation, please feel free to do so.
Looking for the ideal distro. NixOS?
Newbie composer, somewhat-experienced classical guitarist.
Largely known as HisaoNakai/contrapunctus on IRC and other places.
Newbie composer, somewhat-experienced classical guitarist.
Largely known as HisaoNakai/contrapunctus on IRC and other places.
-
Heikki Ketoharju
- Established Member
- Posts: 40
- Joined: Thu Mar 22, 2012 9:24 am
Re: Linuxaudio Wiki maintainers?
I still don't understand why we should list dead links on the site. What purpose it serves? In the history of Internet I haven't heard of any dead links that have suddenly resurrected...
I don't want to see Linuxaudio wiki as an archive for old stuff. There is a great need for simple place containing understandable and easy-to-follow documentation, listnings of actual, working software and guides for beginners and intermediate users. That place, in my opinion, should be the Linuxaudio wiki.
At the same time Linuxaudio Wiki could also easily offer hints about where Linux Audio community currently resides: what mailing lists and IRC channels are at active use? Which web-forum does the community use?
Thing with the tagging system is different if it eases out maintenance work of the wiki. With that system we could just slam a 'deprecated' tag into one place and that link would disappear from several locations. Question is: is there need for links to be in several locations? Is it typical or untypical?
For me it's hard to believe that we have a broad need to put one link into several lists.
Finally: can we easily hide deprecated links from all menus, search functions and other places? And can we easily add some 'deprecated' template to all deprecated links so that on the link page there would reside a big, red warning, like "THIS LINK IS DEPRECATED CONTENT." or something similar?
Because we need a wiki full of actual information, not historical documents. And if we keep all the obsolete fluff for "historical reasons", we must be sure they don't irritate user.
EDIT:
Oh, other question, to TheSafePlaces: have you thought about link rot when planning to move big chunks of information from one place to another? We shouldn't break any links. That's one of the rule of thumbs of the web: don't break any links...
I don't want to see Linuxaudio wiki as an archive for old stuff. There is a great need for simple place containing understandable and easy-to-follow documentation, listnings of actual, working software and guides for beginners and intermediate users. That place, in my opinion, should be the Linuxaudio wiki.
At the same time Linuxaudio Wiki could also easily offer hints about where Linux Audio community currently resides: what mailing lists and IRC channels are at active use? Which web-forum does the community use?
Thing with the tagging system is different if it eases out maintenance work of the wiki. With that system we could just slam a 'deprecated' tag into one place and that link would disappear from several locations. Question is: is there need for links to be in several locations? Is it typical or untypical?
For me it's hard to believe that we have a broad need to put one link into several lists.
Finally: can we easily hide deprecated links from all menus, search functions and other places? And can we easily add some 'deprecated' template to all deprecated links so that on the link page there would reside a big, red warning, like "THIS LINK IS DEPRECATED CONTENT." or something similar?
Because we need a wiki full of actual information, not historical documents. And if we keep all the obsolete fluff for "historical reasons", we must be sure they don't irritate user.
EDIT:
Oh, other question, to TheSafePlaces: have you thought about link rot when planning to move big chunks of information from one place to another? We shouldn't break any links. That's one of the rule of thumbs of the web: don't break any links...