Next steps for this group

[Tony Gravagno]

With CDP and other community resources, we recognize over time certain
deficiencies that we'd like to see fixed one day. I'd like to begin a
discussion about things we'd like to see fixed, and suggested
remedies.

Polling

With questions like "do we pin a Welcome message" all we can do is sit
back for a couple weeks, see what the consensus is, and act or not
based on a manual tally. Google Groups does not include any sort of
polling mechanism, but there are numerous poll utilities on the
internet. To get a good vote, you don't want to leave voting open to
the public because it's subject to tampering and error. A good voting
mechanism needs to allow only identified voters that will only vote
once. (And being from Chicago it really pains me to say that.)

Files

I don't think there is a need for a file sharing mechanism. Someone
can easily post at PickWiki or another resource and post a link here.
That said, a file posting mechanism can be helpful.

FAQ

Jon Sisk was maintaining a CDP FAQ many years ago but it was a single
person effort and, like many such efforts where we place such burdens
on individuals, after some years it was no longer maintained.



I don't like the idea of community resources being hosted by an
individual who may lose interest, fail to do backups, or in any other
way define the existence of something that belongs to everyone else.
PickWiki is such a hosted resource but backups for the environment are
distributed in case of some tragedy.

A few years ago a few of us began a project to upgrade PickWiki to a
MediaWiki environment. MediaWiki supports FAQs and polling and many
other features that people here may find helpful. I had the prototype
for that online until someone who I will refrain from naming here (oh
such restraint) posted an open URL to that as-yet unsecured resource.
MediaWiki includes file sharing, FAQs, polls, and other tools of use
to a community. And because it's a standard and FOSS it can be saved,
cloned, and moved in case of tragedy.

To get that environment up, I need to finish some code which does a
lot of string manipulation to convert the current PickWiki format to
MediaWiki. That will take some time given other obligations here, and
of course I can FOSS the code so that others can assist.

To facilitate polling in the MediaWiki environment as described above,
my approach would be that periodically group managers could export
group membership data to a CSV, run some code on it, then import it to
the PickWiki membership (being careful to not destroy other existing
data, etc (code required) ). That would allow all current members to
vote on current polls.

Why not some other CMS (Content Management System)? Well the migration
of PickWiki needs to be done anyway, we just haven't had time
(motivation, compelling reasons) to do it. That is, after all, a Wiki,
not a general purpose CMS. It just so happens that MediaWiki includes
features that we can use. So since we already (will) have the features
available, rather than changing the nature of that resource, I'm just
suggesting that we make use of what's there. MediaWiki is actually a
CMS with all kinds of great functionality, but at it's heart it's a
wiki, and ideally suited as a replacement for the current aged and oft-
maligned software on which PickWiki is currently based.

So my questions are:
1) What do you think about making PickWiki the home for extended
MVDBMS functionality?
2) Do you have another suggestion which offers both the protections
and the functionality described here?
3) Are polling and FAQs unnecessary extravagances that we can simply
do without? Or do these features add value to make this group more
attractive?

Taking a step back, I am on a mini quest to rejuvenate the community
resources in this industry so that we all have a place to refer end-
users and newcomers. A pleasant and thriving forum is important, as
are resources for things like FAQs, Wiki, Polls, etc. These are
resources that are expected in a "real" marketplace but we're missing
such common "go to" places. PickWiki is already the defacto data
repository for this industry but it needs to be upgraded. We'll work
on that separately. My query here is about how much we should try to
integrate MVDBMS with that resource, just as a matter creating the
common recognition that discussions go here and other features are
there. Or is all of this much ado about nothing?

Comments on the overall initiative as well as the specifics are most
welcome.

Thanks.

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and other Pick/MultiValue products
worldwide, and provides related development services
remove.pleaseNebula-RnD.com/blog
Visit http://PickWiki.com! Contribute!
http://Twitter.com/TonyGravagno

[Kevin Powick]

TL;DR

--

Kevin Powick

[Tony Gravagno]

On Jan 13, 3:56 pm, Kevin Powick <kpow...@gmail.com> wrote:
> TL;DR

Think polls and FAQ add value to forum?
PickWiki upgrade to MediaWiki good solution?

[Kevin Powick]

On Saturday, 14 January 2012 16:31:12 UTC-5, Tony Gravagno wrote:

Think polls and FAQ add value to forum?

A FAQ for/about the forum itself?  Definitely good for the new user or casual browser that comes by the forum by chance.  In a way, it can act as that "elevator pitch" to spark interest.

Polls.  Can they even be done here in a google group?  Only somewhat interesting/meaningful if there is majority participation.  Often tend to clutter forums when overdone or pinned too often, too long.

 

PickWiki upgrade to MediaWiki good solution?

Almost anything would be an improvement.  MediaWiki is popular and you probably wouldn't be left wanting for lack of features, but my understanding is that it is not for the faint of heart to set-up and manage.  Not that it really matters, but I tend to like wikis that do not require a database, so my personal favorite is DokuWiki -- PHP, flexible, easy to set up and administer, easy on system resources.

--

Kevin Powick

[Tony Gravagno]

If you had read the original TL;DR post, your questions and comments
would be completely different.

[Kevin Powick]

But it was TL, so I DR.

I answered the readable, second post.

--

Kevin Powick

[John Thompson]

I think the newcomer piece for the wiki is probably more important
than most people think.
We all may not need it, because we've been doing it for 10+ years,
BUT...

Often PICK/MV gets a bad rap because of so much old code that was
written in the 80's, by lazy, or just plain ignorant folks (meaning
they did not understand how to model the data, etc.). Sadly, the code
has been in production for 20 years, and when another more informed
tech comes along (who may not be all that familiar with PICK/MV) and
tries to add a modern app onto the system or just add a feature, he/
she just looks on in disgust at some of the things that were done, and
assumes that all of PICK/MV is just "horrible"

I've had quite a few of these conversations with folks that are not
familiar with PICK/MV, but, have encountered it over the years (mainly
in the automotive industry).

There was a good idea here:
(But I think it might be the victim of what you described above- It
all falls on one person)
http://www.keyally.com/prdb.html

Anyway, just my two cents, for what its worth.