Community

From RepRap
Revision as of 03:55, 15 January 2010 by Sebastien Bailard (talk | contribs) (Policy)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Working Notes

  • These are working notes.

Library/Needs This page is background and discussion. Library/Needs is where we get the work done.

Policy

  • We're a non-profit library, so we're not going to pull a CDDB or sell out to Yahooglemazon and start charging you and everyone else in order to see your work. (This is the working business model for lots of startups. Sometimes they're sneaky bastards, and sometimes they just need the money, but it's still annoying for the poor users left out in the cold.) This may also be referred to as the We're not bastards policy, as 'don't be evil' is taken by an advertising company/search engine.
  • No Handguns. Sex Toys are ok, but no hand guns. This is slightly more liberal policy than most libraries, but sex is probably a fundamental human right, and sex toys generally make people happy, even if they're embarrassing. Handguns, not so much. Videos and use instruction of sex toys is are inappropriate on RepRap.org as that's what the rest of the internet is for, apparently. Please do not name sex toys after the Developers unless they are humorously large. Sex Toys should probably look like swooshy back-massagers so that casual browsers don't have to explain what they're looking at.
  • The Library is not a link farm. Links to offsite content and links to blog entries are encouraged, but if it's anything good, we'll transcribe/recreate/etc. on the wiki. Carefully cited, and all that, with links to the original post, links to your RepRap profile, and preserving the coplyleft/GPL license you released your work under. If you feel this policy is in error, or feel this cuts into your personal advertising revenue, just join RepRap.org, and help take over the world. And start posting on [email:developers.reprap.org], because hey, you just became a developer!
  • World Domination aka RepRap Without Borders. http://dev.forums.reprap.org/read.php?1,32436 Anything that is fabricable that is not a handgun is open game to get copied into the wiki. RepRappable, LaserCuttable, TableSawable, or BathSalt...able. It doesn't matter, it can (and should) go in the wiki. This includes very politely spidering other peoples sites, copying the most if not all of them into the wiki, and then nicely asking for permission.
  • Can I edit the wiki? I'm not a developer. Yes! You are a developer. So go crazy, log in, and edit! If you see an edit button, it's ok to edit. If you get a "This is locked down" warning, for example on "Foo", create "Foo/Patch". Add a link to Builders if you don't know a better place to crosslink it in on an established page.

(Documentation's important, but it needs to be attached to the image of the part, and the file of the part.)

Aspirations/Working Models

  • Deviant Art
  • Ravelry
  • Wikipedia
  • Thingiverse
  • Debian
  • Archive.org

Motivation, Background, and Urgency

We need a solution that scales to ten thousand parts and ten thousand users.

This is a hard problem in terms of parts library/information science needs and in terms of social-networking/interaction design needs. Our target users are 3rd graders and mechanical engineers. Maybe the occasional museum curator who's willing to digitize his or her collection and GPL it.

We need to figure out if a mediawiki can do this, or figure out the CompSci/User Interface reasons why not and create a working solution.
To do this, we need one hundred different scanned and uploaded items, mostly GPL, with one or two copyleft examples. (Because we have to keep track of the licenses.)

We also need people with server-fu and CMS-fu.

  • In each case, the more we contribute to the commons, the more valuable the commons become to each and every one of us.
  • Positive vision:
  • Negative endgame:

Bugs

  • blog.reprap.org needs to be self hosted by the server. This way we get the advertising revenue, which we can use to fight world hunger, make prosthetic legs and give them away, while still paying for the materials for each developer to make 1 mendel a year, and still have a nice booze-up with the rest of the non-profit funds at the end of the year.
  • The files in Mendel_Drawings.zip are a bunch of pdfs. We need to render the pdfs as .png type image files (using image magick or pdftk?) and embed them in a series of pages. E.g. x_axis_belt_clamp.pdf is a pdf in the zip, we need x_axis_belt_clamp.png, and then either have Mendel/Drawings be one long image dump or have it be a list of pages like: Mendel/x_axis_belt_clamp
  • Users build RepStraps and don't document them on the wiki.
  • Developers build RepStraps and don't document them on the wiki.
  • Users are starting to create RepRap improvements, but aren't comfortable hosting their improvements at RepRap.org.

http://dev.forums.reprap.org/read.php?14,30902,30902#msg-30902

  • RepRap developers are printing neat things, but aren't comfortable hosting their improvements at RepRap.org.
  • We don't have single sign-on for the forum and for the wiki
  • We're using a wiki when we need something purpose-coded/purpose-adapted. It needs to be extensible without wading through crap mediawiki documentation. Mediawiki is poorly self-documented. This is not ironic, this is symptomatic, like an oncologist with a 2-pack-a-day habit.
  • We're using _2_ wikis, are bogged down in the conversion, and we have not demonstrated an ability to rebuild from backups. Are our backups write-only?
  • We're using _2_ wikis. Do our users know this?
  • Our forum software doesn't integrate with mailing lists well.
  • Our forum software doesn't integrate with individual mediawiki pages at all. They're completely siloed, and user/builders get _zero_ feedback for their hacks and improvements.
  • CNCzone folk like to brag about their kit, like car buffs and computer geeks.

Grizzly X3, CNC Fusion Ballscrew kit, 3 500oz-in bipolar steppers, 3 203v Gecko's, Linear power supply from Hubbard CNC, Mach 3, BOBcad Pro Art V22, Rhino.

  • User/builders get _zero_ feedback for their hacks and improvements. Why should they bother to upload, if no-one will praise them for doing anything? It's like throwing pellets of bread into a black hole. (No one feeds the fish, if the fish don't come up to the surface to say "Hi! Thanks for the bread!".) The Library should not show contempt to users in this manner.
  • RepRap doesn't get any advertising revenue for off-site RepRap-like content. This would help pay for developer hardware needs, or "let's loan a machine to a K-6 school for a year and see what happens!"
  • The forum doesn't have any integrated map. People can't have "I live in Manchester, ENGLAND!!! (woo yeah)" in their profile.
  • We have no system for trouble tickets.
  • We need a way to highlight 'cool new posts' and 'cool new scans' and 'cool new projects'
  • We need blog-like capability on the server for users to blog, deviant-art style.
  • [[file:foo.stl] doesn't work but [[image:foo.stl]] does.

Interaction Design

It needs to be able self-host RepRap documentation, but function like other social crafting sites like Deviant Art or Ravelry.com.
Ravelry and Deviant Art are apparently trivial examples, but they are in fact sophisticated reference models for interacation design. They function like facebook or metafilter for their users; encouraging community through chatter, and rewarding the best works through voting and chatter. If we can build the object library using the interaction design rules that Ravelry and Deviant Art have evolved, we will grow the RepRap Object Library to ten thousand parts and ten thousand users very easily and quickly.

We also would like deep integration with our forum. Ideally, the discussion tab would link a forum page. I think this is impossible for mediawiki and phorum architecture reasons. If we have to replace one or the other we will do that, as long as the old links go to the content in the new system.

We will to go with non-inane youtube-style praise comments and [metafilter]-style favorites. Favorites are a positivist praise-based incentive system which also function to highlight the best work on the site. They function due to deep sociobiology principals beyond the scope of this proposal. Short version: kibbiting and gossiping about people's work has been human nature since before the invention of the hand ax. Commenting and voting systems exploit the human tendency to want to be praised for one's accomplishments.

As a negative example of interaction design/social networking, we can consider Wikipedia. Wikipedia is a positive and inspirational example of how to build a vast and somewhat deep body of knowlege. However, it has failed to engage experts and knowledgeable hobbyists but does not reward them with praise and status. Instead, wikipedians gain status through things like wiki-deletionism, wiki-reversionism, and sock-puppets. Domain experts would rather get things done, and would rather not deal with this bullshit.

Mechanisms

Darwin and Mendel are complicated machines, and wiki-type changes like resizing a part can break the design. We need a patches system.

Eventually, we might have to look at computational geometry and a CAD system. This would require a strike force of a dozen computational geometry and CAD software gurus. Explaining the background theory is probably a masters thesis in and of itself. Further discussion is beyond the scope of this page, and is probably the reason Google bought Sketchup.

Patches

Assemblies, Sub-Assemblies, Parts, Daughter Parts, Versioning, and Derivatives

  • What are the formal information-science structures mechanical engineers use to keep track of this stuff?
  • How do we make a system friendly to Mech-E's that is also welcoming to the five-year-old girl who scanned a frog?

Urgency

Once SplineScan takes off, in the next few months, we're going to have lots and lots of files to keep track.

I do not know when we will reach ten thousand files, but we need to be ready.

Scaling

At the ten thousand files point, it is necessary to tie in to a formal database system to keep track of stuff. This server uses MySQL, and we believe we can make use of this.

Technical Description

Stany, you are a sysadmin and know what a MySQL is. Could you give a short technical description of the situation and our requirements? I don't even know if is pronounced 'My sequel' or 'My S-Q-L' . --Sebastien Bailard 12:13, 11 November 2009 (UTC)

Self-hosting

It is crucial to self-host documentation and have it in one place.
This make it easy for users to find everything, since it is all on one website.
This also makes it easy for users to improve RepRap by submitting patches.

This also helps preserve the RepRap 'brand name'.

Names are important, and there are non-obvious ideas and terminology regarding RepRap. It is already difficult explaining the difference between a RepRap, a RepStrap, a Darwin, a Mendel, a Makerbot, a SplineScanner, the RBS, and a Eiffel, let alone what the GPL, CAD-CAM, and a 3D printer are.

Reference Model

Zach Hoeken Smith's Thingiverse is our reference model for the Object Library website. We need to be able to do exactly what Thingiverse does, but better, at RepRap.org, due to the self-hosting issue, the 'branding' issue, and the non-profit issue.

We can't just switch over to Thingiverse because of our Charter: we're a non-profit community based on the GPL, as opposed to Thingivers's charter: [[1]].

Background

  • (What was that website where users uploaded CD track information labels and then the rent-seeking bastard-owners privatized it? That is not how you run a library. Our Charter us from doing this.)
  • RMS's reason for creating/discovering the GPL.

Social Networking