Community

From RepRap
Revision as of 05:06, 24 January 2010 by Jmarsden (talk | contribs) (→‎Bugs: Added comments and responses to some of the 'bugs'.)
Jump to: navigation, search

How to Edit The Wiki?

Log in. Click "edit" at the top, or wherever you see an "edit" link. Edit. Click "Show Preview". Revise if you like. Click "Save Page".

Edit, upload, or create a new page first, then ask for permission later, if at all. Feel free to ask for help putting it in the right place, after it is up.

Q: Should this be in the wiki? I don't know if it's appropriate.
A: Yes. (please). Upload, edit, create a page. And then ask for permission, if you want permission. Also, we have a lovely policy document if you want to know how we run this site. Or why. Because we're very serious about that. And that's what this page is really for, is Policy. Because most people don't read policy documents until there is trouble. And by then, it may be too late.
A2: See our extensive help.

Q2: Can I edit the Policy? This is a wiki, right?
A: Well, we are passionate about archiving for posterity for compassionate reasons and because RepRap is fun. So you can. But you better read the thing first. And think about it. Very carefully. Because we take this stuff very seriously, and 'patrol' this page. And we don't play games with Policy. The best place to discuss and contribute to Policy is in Library Administration, Announcements, and Policy, rather than trying to play games on a wiki where we don't play games.

End of lecture. Happy Uploading and Wiki-Editing and Welcome to RepRap!

Policy

We're a non-profit library

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. We have a sacred trust to maintain this stuff for the commons, frankly.

RepRap is a GPL project, and the spirit of the GPL generally informs our actions in these matters, although we'll host projects,parts, arts, and docs in every license conceivable.

EDIT-EDIT-EDIT-EDIT-EDIT

Everything below this point needs to be rewritten to mean the same thing, but phrased so as not to shock, annoy, or bore Museum Curators, Government Library and Archives folk, etc. I was having way too much fun when I wrote this. And no one else has had a go.

Can I Edit the Wiki

"Can I edit the wiki? I'm not a devel-" "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. This may be known as the "You are all developers policy" (proposed policy - still need supersecret vote from shadow RepRap core team to sign off on this.).

But it's not done yet?

It doesn't matter - share what you have. 3D parts files are good. Even if it is a napkin sketch, or a word-based description. And this is RepRap, so Parts are as important as documentation, and parts come first!. (Documentation's important, but it needs to be attached to the image of the part, and the file of the part.)

No Handguns

Bath Salts are interesting. Some people are even huge fans of Sex Toys, which is great, but no handguns. 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 other 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 to curious children. Undraped and partially sculpture aka Naked Ladies is encouraged, as long as it's not tacky.

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 [developers mailing list], because hey, you just became a developer!

RepRap.org self-hosts files, as much as possible

Part of being self-replicating is knowing where everything is, and having control of your own files, and having ownership and agency of your own toolchain. So we try to extend the site as much as possible, to make sure we have a snapshot of what we consider to be our core technology. There's lots of room under the RepRap umbrella, after all, and every contribution to the RepRap.org commons leaves all richer.

World Domination - We'll wiki the world!

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 archived and made user-readable 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 most if not all of them into the wiki, and then nicely asking for permission, and citing authors. This may also be known as "Embrace, Extend, Ephemeralize".

You are all RepRap Developers

The current policy is that everyone who uses RepRap or makes cool things, all our user/builders, even people who upload to or create other websites and so on is a RepRap developer. So "You are all RepRap Developers". The good news is that this means it's in your power to make RepRap Harder, Better, Faster, Stronger, and the bad news is that this means that, as a RepRap developer, you should patch things and document things when you notice that they're broken. Please use your newfound power wisely.

Play Nice With Others

Here at the library we try to show respect for one another. Which means not ripping individual creators off and uploading their works to the library uncredited. ... On the other hand, huge faceless corporations aren't people, so have fun. Intellectual Property™ lawyers may or may not be people, it's not clear.

Forking May be Fun, but We like to Unfork

While occasional forks and monetization of RepRap related and derivative technology is fun and all, we think there's enough room under the RepRap umbrella for everyone. So we like to unfork the community when files, projects, and documentation gets too spread out by forkers.

I Disagree with this Policy

No problem! This is a wiki, so edit it! Or complain in Library Administration, Announcements, and Policy, where we get very passionate about library matters, forkers, deletion-advocates, and suchlike. It's your chance to make new policy!

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.

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. This is pure unsubstantiated opinion, not a bug report. I disagree. Mediawiki docs contain much info and are how I learned it.
  • We're using _2_ wikis, are bogged down in the conversion, and we have not demonstrated an ability to rebuild from backups. We have now. Are our backups write-only? No. Testing on 2010-01-23 shows they are restorable.
  • We're using _2_ wikis. Do our users know this?
  • 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.

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

Retrieved from "https://reprap.org/mediawiki/index.php?title=Community&oldid=5362"