This tree is deprecated. We chose Drupal.
Please add information/properties as you see fit.
|Easy to update content||Yes: web interface||Yes: web interface|
|Timely security updates||??||??|
|Post meeting information||Yes||Almost: issues with formatting front page|
|Post maps/photos for meeting||Yes||Yes|
|Mailing list/forum integration||??||Yes|
|Match meeting topics and presenters||??||Maybe -- event module|
|Dynamic library page||??||Yes -- steph's plugin|
|Professional appearance||Yes||Sort of: (all Drupal sites look similar)|
|Easy to upgrade||Yes (?)||Yes (?)|
|Easy to customize look and feel||Yes||Not really: there are themes, but we do not know how to
customize the structure
|Calendar support (website events)||Yes||Yes: event module|
|Code quality||Does not validate||Validates as XHTML strict|
|Nice to haves|
|Easy input syntax||??||Yes: bbcode plugin|
|RSS feeds for content||??||Yes, but not for specific forums.|
|Wikis||??||Sort of: book module|
|iCal support for calendars||This should be a wash. phpicalendar will install most anywhere. All built-in calendars seem to have a high degree of "suck." --richard|
|Private Messaging||yes IIRC||Yes|
Include your vote and any supporting evidence you would like to give.
marko votes: Drupal
richard votes: Drupal
john votes: Joomla
Meeting details: next meeting, future meetings.
Feed of what is happening on the mailing lists/blogs/forums.
(I liked the feed in the old PHPNuke site -- pnijjar)
I like the front page very sparse. Like a good business site. Just who, what, where, when, and why in
the most common form. Everything else should be linked below that. --richard.
Links to other content: library, forums, meeting location, about us, site map
(Also see: Child page)
pnijjar votes: not everybody should have admin access, but every member should be able to post content to wikis/blogs/forums. Non-members should be allowed to read everything but not post everywhere.
richard votes: concur. Except the wikis. I don't like wikis. I don't know why. Perhaps because the remind me of clowns.
Maybe a web interface to mailing lists is good enough (see, for example, the Linux Kernel Mailing List frontend.
Counterpoints: the LKML interface is one-way, I think. People cannot POST to the list using the web interface.
Newbies tend to prefer web forums to mailing lists. Integrating the two would allow experienced people to have more interactions with newbies.
pnijjar votes: no. It is better to have no forums rather than forums that are ignored. Integration or death!
richard opines: Let's consider that then. Whack the forums. Use that front page real estate to point to the mailing list only. Less maintenance required. No tricky integration required. Just use a nice mailman (or whichever) page to access. Make the archives prominent, too.
pnijjar votes: keep it minimal -- announcements and discussion, both tied to the mailing lists. If we need further forums then we can create them later.
richard votes: Okay. Announcements and Discussion is fine. Topic / thread separation by Subject: line seems a natural addition and an easy filter to apply with existing tools. But let's keep in mind that we can get rid of the forums too.
The library module will keep track of what books/media are in the LUG library, and who has checked what out. The purpose is to make the library more accessible so that it gets used more.
steph votes: yes, so that people can post reviews of the books.
pnijjar votes: undecided. Maybe people could post reviews to the forums? Maybe to their blogs?
richard votes: no. I like the library. I appreciate the work that went into making the module for us. I haven't heard members asking to review books. I think it will go unused.
Drupal deals with taxonomies and categories. It may soon have support for tagging. What categories should we have?
These tell us what type of posting the person has made.
Items: "review", "howto", "question", "announcement", "event", "meeting", "job posting", "cry for help", "editorial", "rant"
Next attempt: "howtos and tips", "LUG related", "employment", "reviews and editorials", "help me!", "buy and sell", "links and resources", "other events"
This is not perfect but it does have 8 items and not much overlap. It is not clear where politics and ranting would fit in. I am tempted to put something about "announcements" but that should not overlap with "LUG related".
Non-items: "tip" (same as "howto"?)
pnijjar says: we probably would like these to be disjoint if we are making a vocabulary set -- there should not be much overlap between the words.
pnijjar says: we can combine related terms into one category. Maybe we could arbitrarily say we want between 8-10 categories total? Keep in mind that we can create new categories as we go along.
Somebody posted the following list (I think it was me --richard): "business", "expert", "for sale", "hobbies", "howto", "link", "member announcement", "meta LUG", "newbie", "play", "presentation", "regional", "tip", "wanted", "work".
richard throws the list of distros in pnijjar's direction: While we at KWLUG are distro-agnostic, apolitical and care not at all for the whole vi vs. EMACS fracas, is not the ability to search for things related to a specific distro important to our members? From Newbie to Wizard, distro choice implies many things about how you will do things. One taxanomy must be distro. It can be ignored for non-distro posts. And multiple items can be selected when overlap is appropriate.
richard continues; it's a caffeine thing: Taxonomies will also offer guidance to members / posters. Is it possible to select both "Wedding announcement" and "For Sale" on the same blog post? No? Then perhaps I should reconsider offering my new spouse for sale on the LUG.
These tell us what the content of the post is about.
Items: "hardware", "server", "desktop", "distro", "application"
pnijjar says: I don't know how useful these will be.
richard asks: hunh. Is this that tagging thing again? Like taxonomies / categories this is useful if it makes searches easier. If it is only for those infinite font collection tag clouds, I think we can leave it off KWLUG.
richard asks: should we allow grandchild pages?
pnijjar says: When pages are getting very long maybe it makes sense to have granchildren. Until then why not keep things on a single page?
richard replies: I think that was posted to see how the grandchild page / comment displayed. I have nothing against many levels of heirarchy when it makes sense.
pnijjar asks: should we use the book module or the wiki module?
pros of book: it comes standard, it supports revisions.
cons of book: it doesn't have Wiki-syntax, it does not have nice hyperlinking abilities.
pros of wiki: it may allow wiki-syntax, easy linking, it's called a "wiki"
cons of wiki: it is an external module, it is not clear what the advantages are over book.
richard says: Pros of book module. It's not a wiki.
Now pnijjar says: I was wrong. The book module wants every new header to be on its own page, I think. That implies we need lots and lots of grandchild pages.
richard can't shut up: That's okay. Shorter pages are easier to keep the paragraph tags straight.
Add to this list as you see fit, and sign up to do things!
Add a potential web site feture on each child page. Arguments for and against on the grand-child pages? Is this a good way to use the book module?
Provide a calendar display of past, present and future events at the LUG.
Threaded discussion through a web GUI interface appears to be popular with those who first contact KWLUG. Is this because the registered web forum is the best place for their initial contact? Or is it because it is the first type of contact presented to the new visitor to the KWLUG site?
Are the threaded forums required? Would a web GUI interface to the KWLUG mailing list (r/w please!) offer the same ability to post from a browser, but allow contact with a larger audience (namely the mailing list)?
Drupal has made the possibility of individual blogs for each KWLUG member a possibility. What are the advantages and disadvantages of KWLUG member Blogs? What is are the uses for a blog, versus a forum post, versus a mailing list post?
Member blogs have their own RSS feeds. Interested readers can syndicate just the writers they choose to follow, or all of the KWLUG bloggers at once.
Okay, this page is a softball.
The mailing list subscribe, confirmation and unsubscribe controls should be available from the web site. The archive should also be available.
We meet monthly, usually on the first Monday of the month. Please check the Next Meeting link for details. There is a parking lot behind the building and parking after 6pm is free (last time we checked). We meet at:The Working Centre
Want to find us on a Map?
Meetings are free and open to those with an interest in Linux. All levels of Linux experience are welcome at our meetings. Come on out and meet us.