RepRap and skdb+wiki
Sebastien Bailard
Here are folk who might enjoy testing/working on skdb+wiki:
Tony Buser (tbuser)
http://reprap.org/wiki/User:Tbuser
Prusa
http://reprap.org/wiki/User:Prusajr
Also, I was just talking to Tim and Rob and they're both very
interested in what you're doing and wants to be involved. They tend to
think infrastructure is sexy and want to make sure that
skdb+ikiwiki+proposed_project_management_software meets their workflow
needs and wants.
-------------------------
This is my sense of our wants and needs:
* Wiki functionality.
As per phone discussion, we don't want a new system to have less
wiki functionality compared to our in-place mediawiki. We need to
demonstrate that before talking to reprap-dev.
For example, what would http://reprap.org/wiki/Prusa_Mendel look
like using your stuff?
* git to wiki, wiki to git.
Besides, wiki, reprap's existing infrastructure, we'd want to
demonstrate the git->html stuff, and the drive-by upload -> git
stuff. With RepRap, that's currently siloed. It's currently
effectively pointless to upload openscad files to the wiki, the wiki
doesn't know about what's going on in git, etc. significant
user-education issues, etc.
* rich user pages that automatically show contributions and social networking.
Imagine Tony Buser's page, but like this:
http://vanheist.deviantart.com/
and with favoriting of comments and contributions, like
http://www.metafilter.com/activity/15862/favorited/
(Metafilter does this well. Let me know if you want a screen shot)
Youtube, thingiverse do it well as well. Mediawiki does this on
wikipedia, but not for reprap due to ease-of-use and
lack-of-community issues.
This is one of nophead's needs. "I can't find my stuff"; mediawiki
user page doesn't automatically display contributions.
This is one of everyone's needs. "I get no feedback, no one values
my contributions." Favoriting needs to work on on the project page,
on the project dev's user page, and on the user page of the guy
who-clicked "favorite this".
* Prettiness.
Vanilla ikiwiki isn't pretty, we'd want to use a
reprap-localized stylesheet from http://ikiwiki.info/css_market/
before waving it at reprap-dev. Beauty helps with presentation.
* Blogging.
Currently, all blogging is siloed from wiki. ikiwiki does have some
blogging functionality, but the blogs I saw were using non-pretty
css skins.
* In-page commenting.
The mediawiki currently uses discussion pages. But mediawiki-naive
devs never look there. Built-in chatboxes with metafilter favoriting
will help. I think we'd want to show the avatar( photograph/headshots
* Dependencies for machines and subassemblies, BOM.
You've thought about this, I'm sure. RepRap wiki doesn't do this
worth a damn. It could, with semantic mediawiki, but too much work,
too much user-education, and still siloed from git.
This is one of Vik Oliver's needs.
* wysiwyg wiki editting.
Would be nice. Our current wiki population doesn't always know how
to do an internal link, [[Mendel]], and will input
http://reprap.org/wiki/Mendel into the wiki page instead. (Arrgh!)
I took a quick (30-second ) skim-google, but I'm not sure how well
the current ikiwiki wysiwyg plugins work.
wysiwyg is one of Dave and Adrian's wants/needs.
* Markup Language
Vanilla ikiwiki's markup language is a bit different from mediawiki. I
think we'd want to use Creole, which is a closer match.
http://ikiwiki.info/plugins/creole/
http://www.wikicreole.org/wiki/
* Archiving our old history.
David Buzz went to quite a bit of work to transition
twiki->mediawiki, and transitioned the history pages from the twiki
pages to the history pages associated with the mediawiki
pages. (He's a perl guru). He'll get warm fuzzies if we figure out
how to do it again. I'm more concerned with reprap's future than its
history, but he's got a point ...
-------------------------
I think we're best off using #reprap to talk about this, along with
http://groups.google.com/group/openmanufacturing
reprap-dev probably isn't going to sign off on a
mediawiki->skdb+ikiwiki transition until they see it working, so I
don't know if we should show it to reprap-dev until we've got a sense
of where we are and where we're going. We will want to involve them
at some point, but I'm not sure when to engage them.
I'm not sure how much you want to talk to Dave Buzz and Jonathan
Marsden (jmarsden on irc) about it, until we have some functionality.
Dave may be open to working on it, whereas Jonathan can be very
conservative in his ways and just wants me to polish the mediawiki and
stop trying to organize a post-mediawiki working party. When speaking
to folk, I'd suggest saying that we're "working on a proposal for
something that may work better than mediawiki"; it's less provocative
than "Sebastien's going to rip out the mediawiki tomorrow and load
this in", which would lead to quite a bit of discussion and conflict.
:D
At some point it may make sense to use the blog and reprap-dev to
recruit devs to work on this, or it may not. RepRap does have a lot
of social capital, but I've read that throwing additional programmers
at a project sometimes makes it take longer.
------------------------
I'm glad you're working on this stuff, guys. RepRap needs folk like
you.
Cheers,
-Sebastien
Bryan Bishop
> * In-page commenting.
>
> The mediawiki currently uses discussion pages. But mediawiki-naive
> devs never look there. Built-in chatboxes with metafilter favoriting
> will help. I think we'd want to show the avatar( photograph/headshots
How exactly do you wish this worked? To be honest, I think thingiverse
does this very poorly (Zach uses js-kit.com). A giant thread of
comments for the entire project, that's not really ideal. But it is
pretty simple and quick to implement.
Traditionally, every project gets itself a mailing list (sometimes one
for users, one for developers, and another for announcements if
necessary). I don't feel good about having to write my own mailing
list wrapper into a website, but it makes sense as a solution.
So, if I do end up just implementing comments on a single page,
there's a few open questions. First, if you do
just-throw-all-comments-on-the-same-page, you'll have to let users do
subscribe-to-comments-by-email. My worry here is that users would end
up with email subscriptions to all sorts of weird things (comments for
each project, commits for each project, bug tracker, etc.) I suppose
this could be fixed with a digest email for high-activity projects.
How do you envision this working-- ideally?
Sebastien Bailard
I hadn't really thought about the comment<->email gateway stuff.
Partly, we may not want youtube-style comments spilling over into the
dev list. (They tend to be slightly fluffy.) But we still do want
commenting.
I'd been thinking that 'subscriptions to all sorts of weird things
(comments for each project, commits for each project, bug tracker,
etc.)' would actually get pushed onto people's home pages. Rather the
way metafilter does things.
I do like commenting systems that allow folk to upvote the comments of
their peers, which mediawiki does not do. Also, would we want to use
the same commenting system for blog post comments?
I'm not really sure how email would interact with this; I imagine the
site would email people when their homepage had activity.
Regards,
Sebastien