[Cabal] FAQ and support.pidgin.im

[Luke Schierer]

On Mon, Oct 30, 2006 at 09:02:32PM -0500, Evan Schoenberg wrote:
> 
> On Oct 30, 2006, at 8:51 PM, Luke Schierer wrote:
> 
> >There are two ways to do a FAQ in a wiki.
> >
> >1)a single FAQ page.  This is not substantially different from our
> >faq.txt and faq.php pair, and has all of its flaws.
> *nod*
> 
> >2)to make each question/answer pair its own wiki page.  This would be
> >more or less equivalent to what faqomatic is providing, each category
> >would be a page that is itself a list of links deeper into the wiki.
> >The leaf pages would have answers.  The problem here is that Wiki  
> >links
> >are ugly.
> A momentary argument against: There's no need to use Wiki formatting  
> to do links... [wiki:WikiPage Your text here].
> 
> I'm used to it, but I can see how that would be a mildly obnoxious  
> requirement for doing links.  I don't know if faqomatic's format is  
> better.

It is very specific to creating a faq, so you just click a link to
insert a new question, and it asks for the title/question and then the
answer text.  Ditto for a new category.  Very simple, no extra knowledge
necessary.  

> 
> >I would be more inclined to this approach if we were going to put the
> >faq in developer.pidgin.im or if trac were running pidgin.im itself.
> >Given that it is not running pidgin.im, I think we have the  
> >opportunity
> >to have a set of support pages that more narrowly focus on users vrs
> >developers, and then have developer.pidgin.im do the reverse.  We can
> >perhaps better serve the needs of this overlaping, but in some  
> >respects
> >very different sets of users.
> If the choice is made to treat Trac as purely a development  
> environment, I can see how that makes sense.  My thought of Trac as  
> an intentionally user-and-developer environment is that it blurs the  
> line between the two, letting users take an active part in  
> improvement of the program by easy access to bug reports, easy cross- 
> referencing to wiki entries from reports, and so on.  Maybe trying to  
> be inclusive like that just annoys the crap out of users :)
> 
> -Evan

This is tempting.  I know wordpress does things more or less this way.
I also know that their wiki is a good place to get lost in, but it is
equally clear that this is not inherent in the usage of trac, but rather
in that they seem to have had 2 or 3 different support setups and to
have removed none of them.  

Which leads me to a tangental point.  When we do make pidgin.im public,
I will be closing the sf trackers to prevent new submissions. Ditto its
forum.

Getting back on topic, if we go this route, support.pidgin.im would just
be some redirects to allow for short urls to specific
developer.pidgin.im wiki pages.  or support.pidgin.im would not exist at
all.

We have a substantial set of users who want very little to do with
development.  They expect a solid product, and are upset with us when we
fail to meet their expectations.  This class of users will be annoyed by
integrating developer.pidgin.im with "support" functions beyond the
trouble tickets themselves.  But they are also a class of users that I
really don't like encouraging the existance of.

I don't want another forum, but if it were to be realistic to allow even
somewhat open editing of the wiki pages, the trac install at
developer.p.im could fill what little good there is in having a forum -
users providing some of the answers, without the more obvious flaws.

faqomatic could also do this, but then we'd have two places for such
helpful users to have a presence, in which case we are likely to be
presenting too high a bar for participation.

luke