Library/Notes

From RepRapWiki
Jump to: navigation, search

These are public notes, but they're extremely chaotic, and somewhat contentious. --Sebastien Bailard 06:20, 29 January 2010 (UTC)


Contents

Recommendations for RepRap Parts and Documentation

We're still sorting this out.


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. (Library/6x10000s Problem).

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 help the David Project by digitizing 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 that need to be moved into Bug Tracking

"What is a bug" is part of the Policy debate. Like forked projects, parts, arts, and docs. That debate is currently in Library Administration, Announcements, and Policy, until we decide to set aside RepRap development in the developers-list forum in order to argue over how to order around the people who run the Library, and what we are ordering them to do.

This page will to be completely cleaned up, but I'm keeping a brief "How to use the wiki" note at the top for user-developers who came in here by mistake. --Sebastien Bailard 19:48, 24 January 2010 (UTC)

  • http://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 (Below-The-Knee Prosthetic) 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.
  • We need to move everything extruder-related under Extruder, Extruder/Lasercut. Done. We just need to remember to slap [[category: extruder]] on any new pages that are extruder-related.
  • 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.
  • wishlist: a stack of paper instructions showing *everything* a person need to build (the mechanical parts of) a particular RepRap or RepStrap -- a complete BOM, list of required tools, assembly instructions.
    • Perhaps start with a one-page summary of what a RepRap is and a few pretty photos of things it can make -- Reachout, ShowCase -- for quick explanations at events such as NYC Maker Faire.
    • Perhaps somehow use the Wikibooks:Help:Collections technique for making a single document from the latest version of many wiki pages. So the person who prints it out can be sure that he's getting the today's version of the drive train, electrical wiring, and toolhead assembly instructions for whichever combination he's selected.
  • We don't have single sign-on for the forum and for the wiki
  • We're using _2_ wikis. Do our users know this? Nope. Hasn't this been fixed already?
  • 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. There is provision for custom profile fields in the software. Forum admins just need to configure it. Once a location description field, and (more usefully for maps!) latitude and longitude fields are there, adding maps as a module would probably not be a huge software development task.
  • We have no system for trouble tickets. Please try to be constructive. State which one of the many free ones out there would you like to see implemented, and why.
  • 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.
  • A list of so called 'bugs' is not policy, (unless we want them to all stay as 'bugs' forever!?), and so this is almost certainly not the right place for it. Note that an undifferentiated list of oneliner criticisms, without details of why the statements made are in fact bugs not just wishlist items, info on how to reproduce the bugs, etc. is not really a usable set of bug reports suitable for constructive future project development to use as any basis for further improvement.

Agreed. This page started as a public place to store bug and wishlist items and mutated into a sketch of Policy. I'll clean it up pronto. Discussion needs to move off this page.--Sebastien Bailard 19:48, 24 January 2010 (UTC)

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 (Wikipedia:Richard Stallman) reason for creating/discovering the GPL.

Social Networking