Public SourceMage Discussion List

["Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>]

Some of us[0] discussed this some more on IRC, and we agreed that we think
the following makes the most sense:

1.  We should continue to maintain a wiki for developing documentations,
    specifications, policies, etc; basically, the wiki will be the
    developer-facing web place to propose things and work on them til
    they're complete.

2.  When things on the wiki are complete, they should get moved to the Drupal
    site.  The Drupal site will be the public-facing site, with only final
    content.  It will combine this content with forums, blogs, and other
    user-facing functions that Drupal integrates well.

3.  It should be the individual Team Leads' responsibility to make sure
    things in their areas of the wiki that are complete get moved to the
    Drupal site in a timely manner.  The Tome team and the Project
    Lead/Asst. Project Lead will be available to help with this, but it
    will be the TL's job to make sure it gets done.  Drupal will remain
    editable only by those who have edit permissions, which includes the
    Tome team, the Leads, and their designees.

This should address all of the points raised below except for (6) and (7),
which, again, are largely implementation issues and can be addressed with
most any technology we use.

How do the rest of you who have an opinion feel about this?  A question yet
to answer would be who would have either read or write access to the wiki.
We would want to make it useful for what it's intended for without creating
a scenario where it just takes over the role of the Drupal site for
content, because that just makes the Tome team's job harder.  The most
draconian approach would be to only allow registered developers to read and
write the dev wiki.  A more open approach would be to let anyone read it
and any registered user approved by a TL edit it.  Thoughts?


[0] Participants included myself, sandalle, Kinetix, swoolley, afrayedknot,
BearPerson, and ruskie.  The log is attached.


On Oct 21, Jeremy Blosser (emrys) [jblosser-smgl AT firinn.org] wrote:
> I'm bumping this back to the list to restart this discussion in the context
> of getting our site back up and running.  There were responses already
> given to some of these; those can be viewed in the archives around here:
> 
> https://lists.ibiblio.org/sympa/arc/sm-discuss/2005-September/thread.html#12520
> 
> But I particularly want to hear what feedback Adam has.  Adam, hopefully
> you have time to talk about this now as we're getting stuff restored, I
> think it's highly relevant.
> 
> On Sep 27, Jeremy Blosser (emrys) [jblosser-smgl AT firinn.org] wrote:
> > One of the 1.0 targets was to "Install a CMS-type software to integrate 
> > the
> > pieces to the Web site".  This is done as far as installation goes;
> > however, to be really considered complete I think we need to have the
> > content from the Wiki moved over and available as well.  Unfortunately the
> > Drupal site appears to be having some issues with acceptance from the
> > developers; the docs are being moved only slowly, and quite often people
> > who are working on converting things are heard to complain that there are
> > things about Drupal that they have issues with.  I would like to start a
> > thread here to ask some questions and hopefully get this all resolved.
> > Note, I'm not asking these as someone with a particular technology agenda
> > or because I want to denigrate anyone's work so far, I'm just interested 
> > in
> > getting our developers into a site they find really useful.  My hope is
> > that the Tome team will have ready answers to all of these and time to
> > implement them, and won't hate me for organizing the questions and asking
> > them.  Don't shoot the messenger.  ;-P
> > 
> > First questions, for my benefit since I wasn't necessarily around for all
> > of this:
> > 
> > 0) What about the old wiki was so fundamentally broken that we decided to
> >    switch to an entirely different technology?  The main thing the people
> >    I've asked have told me is that the wiki had a spam problem, but it
> >    seems this could have been fixed inside the technology we had instead 
> > of
> >    implementing something so different it requires porting everything 
> > over.
> > 
> > 1) I'm vaguely aware from parts of past conversations I saw that Drupal 
> > has
> >    some kind of wiki module available as an alternative to the book 
> > format.
> >    Depending on what this offers it could address several of the concerns
> >    I've heard raised, so can I ask why we decided against imeplementing it
> >    so far?
> > 
> > Second set of "questions", these are some of the specific gripes I've 
> > heard
> > raised about the Drupal site:
> > 
> > There are several under the general idea it's too hard to add content.
> > Specifically:
> > 
> > 2) You have to have permissions as an editor.  The wiki of course allowed
> >    anyone to edit, and this led to a spam problem.  A common opinion
> >    however seems to be that the Drupal site goes too far the other way, 
> > and
> >    that anyone with a registered account should be able to edit pages.
> > 
> > 3) The available page formatting options are either too slim or "full
> >    HTML".  The filtered modes allow a very few HTML tags or BBCode.  This
> >    mostly amounts to bold/em, lists, and font colors, as well as a couple
> >    other pre-formatted block modes.  There is no provision for things like
> >    headers or other block elements.  You can do full HTML to get
> >    everything, but consensus among many is that they don't know HTML and
> >    don't want to, and that the Wiki tagging was good for this.
> > 
> >    (On the flip side, as someone who knows HTML, I'm glad to have the full
> >    formatting option available; there were some things that weren't
> >    possible on the wiki for me.)
> > 
> > 4) There is no real "hypertext" method for adding subpages.  In a wiki you
> >    can basically just reference a page that doesn't exist yet and then go
> >    create it; subpages are created organically and the site grows
> >    naturally.  With Drupal's books, to create a subpage you have to do
> >    'create content' again and then find the page you just made in a drop
> >    down and make your page off of that.  It's much more organized and also
> >    a good bit slower.
> > 
> >    (As someone with an information architecture background, organic site
> >    growth ala a wiki is horrid to me for actual user browsing, but I know
> >    it's the best way to get people actually contributing.  Ideal would be 
> > a
> >    system where contributors could add content organically and then the IA
> >    could be cleaned up easily later.)
> > 
> > 5) You can't get diffs between revisions of a book page.  This is a big
> >    deal, since often we want to use the site to work out policy and
> >    technical design stuff.  If we can't easily see how a document has
> >    changed through revisions then this format is quite simply useless for
> >    collaborative document editing, there's really no two ways about that.
> > 
> > Then there are a couple things that are probably just how this site is
> > implemented:
> > 
> > 6) It's a good bit harder to find things on the new site.  The old wiki
> >    index page had everything and was organized very well, especially for
> >    something that had content added organically.  With the new site you
> >    basically need to ignore the navigation options and use the search to
> >    find things.  I think this can be fixed with just some more time spent
> >    on the IA and navigation, but it needs to be addressed.
> > 
> > 7) The style of the new site is more difficult to read.  The content 
> > column
> >    and font sizes are significantly smaller, there's a lot of excessive
> >    whitespace, stuff scrolls horizontally a lot more and less evenly, etc.
> >    As someone noted before, compare
> >    http://wiki.sourcemage.org/index.php?page=The+Source+Mage+Developers
> >    to
> >    http://www.sourcemage.org/developers
> >    for plain readability, there's really no contest.  Several people have
> >    said they've tried to use the code blocks on the new site and just 
> > given
> >    up on them because they are overformatted.  Fortunately all of this can
> >    probably be resolved by just simplifying the style sheet(s) we're 
> > using,
> >    perhaps using the old wiki default style as a guide.
> > 
> > Last questions, to get some resolution to these:
> > 
> > 8) Are any of these resolvable in Drupal now, using additional modules or
> >    configuration, etc.?  Which?
> > 
> > 9) For those that aren't, what do we do?
> > 
> > 10) Does the Tome team currently have time to work on these?
>

Attachment: irc_drupal_wiki.log.bz2
Description: BZip2 compressed data

Attachment: pgp7B8aLkf6hx.pgp
Description: PGP signature