Having a RepRap issue tracker and RepRap bounties.

... somewhat lengthy, but it's $$ in it


RepRappers,

if you followed a number of other recent topics and how finding ways to fund RepRap development without selling this development may enhance attractivity. I just chatted with some people from bountysource.com on how to integrate their infrastructure into the RepRap universe. Other than Kickstarter and IndieGoGo, Bountysource allows (next to fundraisers) to open bounties for issues on existing developments.

The basic idea is: if you found an issue with, let's say, a flaw in the design of the Sanguinololu, open a bounty, pledge a few Euros or Dollars, drum up a few others to pledge, too, and see some developer coming around fixing the issue. Or similarly, as a developer, open an issue offering an enhancement and do the work if sufficient backing came in, allowing to do the work and a prototype. This way the development is paid directly, copiers will likely pick it up.

What Bountysource needs is:
a) a person identified to have done the work
b) a confirmation the work is actually done.

It turns out Bountysource has no own tracker and these people, being software developers, strongly recommended me to move sooner or later all(!) file hosting over to Github. Well, I neither see myself moving every single project in the wiki over to Github, nor how all the existing developers suddenly prefer Github and start maintaining their baby there. Some do already, but by far not all. As we all know, RepRappers tend to have their own mind and the wiki is well established.

RepRap needs its own bug/issue tracker. A tracker totally disconnected from any source code management (SCM) tool like Subversion or Git. Because we often have no source code and many of our wrench and screwdriver artists (no pun intended) have not the slightest idea of how Git works.

Am I on the right track so far?

Basically this means another reprap.org site next to forum & wiki. Similar to the wikis' talk pages, there'd be a list of issues/bounties on each wiki page and a button to add another one. This way it should be dead simple to add issues and/or pledge an amount to get the issue fixed and/or the enhancement into place. No obligation to developers, they can bring in their results the way they want.

The technical side: they support Trac, Bugzilla and Jira^[1] for hosting by reprap.org and Github, Sourc... well, scratch the hosted ones, they're all about software.


What do you think?


[1] Jira is commercial, but hands out free licences to open source projects.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hmmm, yes staying off of Github might be a good idea. I don't really see how it can work well with hardware. The wiki works because you can use photos and diagrams easily.

---

Yvan

Singularity Machine

Traumflug,

Well done for getting this started. Please let me know if there is anything I can do to help.

All the best,


Senake

Quote

Please let me know if there is anything I can do to help.

You can. Look around and find ways how to connect things. On bountysource you find a number of repos using this service already, so finding one which matches RepRaps' requirements well would help. If you see links pointing to Bountysource which look attractive and usable, show them. Much of the success of this story will depend on visual appearance and ease of use. Wiki pages allow pretty much arbitrary HTML code, so whatever you see on a web page, can be inserted there, too.

If you want to go more in depth, I can give you an account on reprap.org to enable you installation of this software(s). Two people working on something are typically three times as fast as a single person.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

There's at least one other provider of this service: [www.fossfactory.org]

If you feel a need for a service hosted at RepRap, here's sort of a starter kit: [selfstarter.us] The latter have an interesting story: [techcrunch.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Github would work fine. There's absolutely no reason why you need to transfer any projects into github, I don't know why you would even think that. We would just use the issues tracker, and commit metadata. It can just be a text file with a URL to where the request has been fulfilled.

There is no reason why git is limited to software. If you can describe things in words or data, you can use git for hardware. There is nothing magic about hardware.

Obviously git presents a new tool to learn, but that applies to anything! In fact most of the git stuff we wouldn't use, and if you can use a web interface, you can use github.

Github is ready made platform that does what we want, we should at least try it.

Quote

Hmmm, yes staying off of Github might be a good idea. I don't really see how it can work well with hardware. The wiki works because you can use photos and diagrams easily.

You get a wiki with each Github project if you want to have pictures, etc. Also if your project contains pictures, for example the Mendel90 has assembly views for the manual, then the difference view between versions shows how the pictures change. It has four ways of differencing two pictures. It also shows great 3D views of STL files that you can rotate, pan and zoom, much slicker than Thingiverse.

I don't find wikis useful for projects that have lots of versions and updates. When I make a new version of Mendel90 I can update github in seconds but it would take hours to update the wiki as all the resources need uploading one by one. It would then be hard for people to find old versions to match what they had.

In my opinion the Reprap wiki should just have information that doesn't change over time (and therefore need revisions) and should just have links to projects on Github that do.

---

[www.hydraraptor.blogspot.com]

To those of you who know how to use Github, it's a great tool. I think the problem is it's not obvious to people unfamiliar with Git what the best way to utilize the service is (such as me). Git can also be intimidating to navigate for people who are not familiar with it, and are not familiar with the project (let me tell you about the first time I tried to locate a particular STL file in the Prusa repo...)

If we could set up a "best practices for hardware projects hosted on Git" I think that would go a long way towards solving these issues. That way all RepRap-related projects would have a familiar basic structure.

A related issue is documentation. I'll pick on Cura since this is fresh in my mind, but many are guilty of this. Cura allows you to use variable names in your custom start and end gcode, to set things such as the print head and bed temperatures. Unfortunately, these variable names are not documented anywhere on Github or Cura's page on the Ultimaker site! The only way I figured out what they were was to corner Daid in IRC and ask him. My point is, people need to document their project's features. There's more to it than pushing commits with terse changelogs.

nophead Wrote:
-------------------------------------------------------

> In my opinion the Reprap wiki should just have
> information that doesn't change over time (and
> therefore need revisions) and should just have
> links to projects on Github that do.

Amen. The reprap.org wiki is pure chaos.

---

- akhlut

Just remember - Iterate, Iterate, Iterate!

[myhomelessmind.blogspot.com]

I half expected people to chime in and say Github is good for RepRap hardware projects, but I wouldn't know where to start. Around here Github seems to leave people wondering why it is set up the way it is.

The wiki is chaos, that is for sure, but Github seems optimized for something else. Something we don't seem to be using collectively speaking. Where is the middle ground I don't know.

I think if Github could be made to work that would be great. I wouln't know how to start, and that might be a clue as to why it is not a good match!

Edited 1 time(s). Last edit at 10/10/2013 12:13PM by Yvan.

---

Yvan

Singularity Machine

Thanks for all the input.

Quote

There's absolutely no reason why you need to transfer any projects into github

The reason is, if you want to track a project on Github, you have to actually have the project there.

Quote

Obviously git presents a new tool to learn

That's exactly ths point I try to avoid. Requiring a learning curve disencourages participation a lot. Many RepRappers aren't software developers, so they don't even know what SCM is, much less how it works. For example, uploading a patch to Github is a pretty complex procedure (fork, clone again, move the changes to the new repo, commit, push, submit a pull request). They disallow uploading files other than pictures.

Another problem is, Github allows write access to project participants, only. What if a project got abandoned by it's creator, still someone wants to enhance it? Won't work. Over the years, many many RepRap developers simply disappeared from one day to the next. The wiki pages are still there and accessible, the repos are not.

That said, nobody shall be prohibited from using Github. Using a SCM tool is one reasonable way of many.

Quote

You get a wiki with each Github project if you want to have pictures, etc.

You do, and you end up with hundreds of separate wikis when promoting this.

Quote

In my opinion the Reprap wiki should just have information that doesn't change over time (and therefore need revisions)

Agreed, revisioning isn't ideal in the wiki. Older revisions can be accessed, but neither convenient nor branchable. I wouldn't count issues/bounties directly connected to revisions, though. Issues appear and disappear mostly independent of what the current revision is.

One big bonus of the wiki is it's visibility. People see something nice instead of a cryptic list of files. Looking at recent Kickstarter projects and talking to their backers I have a pretty strong impression these people are mostly interested in technics, but not neccessarily educated or experienced there. They decide for a fair share by "looks good", "makes fun" and "sounds interesting".

As a result of this I think keeping the bounties interface good looking and very easy to navigate is an important part. No problem if the project is managed on Github behind the (newbie visible) scenes.


Generally, please continue coming up with additional and different points of view. I have formed my opinion carefully, but this doesn't mean its right in every aspect. Perhaps I'm even on the entirely wrong track.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

Amen. The reprap.org wiki is pure chaos.

... says somebody who has a total of one wiki edit. Please don't slap those working and cleaning up there daily.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Not sure if this is of interest, self hosted. [sparkleshare.org]

---

Random Precision

Quote
Traumflug
The basic idea is: if you found an issue with, let's say, a flaw in the design of the Sanguinololu, open a bounty...

In my opinion, the RepRap wiki seems to be quite well structured at a top level, but adding to it is - only marginally - more of an chore than just posting something in the general forum. I am very guilty of this too with my inadequately researched post on whether arc welding could be used for metal printing.

Quote
Nophead
You get a wiki with each Github project if you want to have pictures, etc. Also if your project contains pictures, for example the Mendel90 has assembly views for the manual, then the difference view between versions shows how the pictures change. It has four ways of differencing two pictures. It also shows great 3D views of STL files that you can rotate, pan and zoom, much slicker than Thingiverse.

A picture is better than a thousand words - and a 3D object is better than a picture - and a 4D object with a timeline adds even more value. If GitHub already has this functionality, then all we have to do is create a seamless click through into the relevant 3D/4D object (1) from the RepRap front page to GitHub and (b) from one GitHub 3D/4D object to another as we zoom down into sub assemblies within it.

Quote
Traumflug
One big bonus of the wiki is it's visibility. People see something nice instead of a cryptic list of files. Looking at recent Kickstarter projects and talking to their backers I have a pretty strong impression these people are mostly interested in technics, but not neccessarily educated or experienced there. They decide for a fair share by "looks good", "makes fun" and "sounds interesting".

To expand the audience of the wiki and respike the general public's interest in participating in RepRap, it may be worth portraying "the dream" on the front page in a simple clickable pictorial format - possibly like one of those pictures where lots of things are going on and you learn something new every time that you look at the picture. We should canvas everyone's thoughts on what should initially go into the picture and add to it as more beneficial uses for 3D printing come up, but here are my thoughts:

1. A view of a life in:
a. The city and;
b. The countryside and;
c. The seaside and;
d. The sea (above and below the surface) and:
e. Above the ground (showing aeroplanes and aerial wind turbines) and;
f. In space (showing asteroid mining and space travel)

2. Based partially on everyday life now and life in the future, this should depict uses of 3D printing ideally in a micro story format maybe using speech bubbles (most successful startup pitches tell a story). Some examples would be:

a. Kids getting their meals out of a food printer whilst their mother enjoys some leisure or study or tinkering time with them.
b. A doctor printing off a kidney to transplant into a patient.
c. A place or people who live in abject poverty now using readily available resources around them - plants and trees, water and earth - as raw material to 3D print out new homes, furniture, solar panels, smartphones etc.

We probably don't have the dev time or skillsets required now, but in future, it would be great if these mini scenarios could be turned into little Toy Story style 3D animated clips.

The "our dream future with 3D printing" image for the RepRap home page could look something like this, but with the scenarios described above.


As there would be a lot on this home page, detail should probably appear as you zoomed in - like on Google Earth/Maps. Clicking on the 3D food printer would take you into a 3D GitHub hosted 3D view of a machine eg. With an aquaponics back end and a food printing front end. Everyone would be able to use this to see the latest and greatest solution (or variants for different material types/uses) - and suggest an improvement if they could think of one.

Importantly, so that people could see that this was not just a pie in the sky dream, RepRap devs should also be encouraged to post amateur videos of trials and experiments that they carried out like this - RichRap food printing showing progress made.

At the side of the "dream" picture would be a scrollable list of activity so that people would be reassured that their comments would also have general visibility if posted in the relevant content - the aim being to get away from random postings in a General forum that get lost on page 12324685 after 3 years.

This structure would also allow new innovative contributions to be recorded and potential users of functionality to be identified so that bounties could be created. If bounty fulfilment opportunities and registration - were linked to the relevant GitHub 3D objects, then it would be a motivation for devs and potential new members to look in these areas too.

*** Apologies for the lengthy post - I hope it was constructive ***

Edited 5 time(s). Last edit at 10/10/2013 09:19PM by Senake.

Might it be a good idea to schedule a Webex (or free open source equivalent) to thrash around a few ideas on screen - maybe sometime on an upcoming weekend or night?

I would especially love to see a demo or walk through of this functionality:

Quote
nophead
You get a wiki with each Github project if you want to have pictures, etc. Also if your project contains pictures, for example the Mendel90 has assembly views for the manual, then the difference view between versions shows how the pictures change. It has four ways of differencing two pictures. It also shows great 3D views of STL files that you can rotate, pan and zoom, much slicker than Thingiverse.

Edited 1 time(s). Last edit at 10/10/2013 09:50PM by Senake.

I guess it's time to come up with idea visualisations.

Whoever wants to see something, please implement it. By running actual code, by photoshopping pictures of GUIs, by writing mock-ups in the wiki, on Github or wherever you think your ideas should be placed.

Whoever needs server space on reprap.org, please tell me and I'll prepare it, including a shell account. Apache, MySQL, PHP are running already, more is possible. Setting up an account is a matter of a minute only, so feel free to try and experiment.

When people start to see buttons, many likely get a much better idea of what one solution or another means.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Just a quick question here...would it be possible to code a new front end for Github? Is there a API available?

Joseph

Quote

Just a quick question here...would it be possible to code a new front end for Github?

[developer.github.com]
[garyhodgson.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I think this is a great idea and will be following it with interest.

I have been following (and participating on the fringe) the RepRap movement for years now. As with many others, my personal commitments have meant that I have contributed less than I'd like.

I would however like to add these points: I agree with the reasons why nophead says that GitHub is better than the Wiki, however I think as Traumfllug is saying, we need to resolve those issues, and ideally in a way that will suit novices or those with limited time.

If things were simpler, I am pretty certain I would contribute more. Specifically the following quote is relevant.

Quote

For example, uploading a patch to Github is a pretty complex procedure (fork, clone again, move the changes to the new repo, commit, push, submit a pull request).

I have been a software developer and manager of software teams for over a decade now. I have many years of experience in software patching and code management, however my experience is in the Microsoft arena. I have been working on a Mendel90 and having joined GitHub and cloned the respository, I find it quite confusing trying to figure out how to commit and submit pull requests to nophead. Each time I have tried I have only have a short amount of time available, and have ended up spending most of the time progressing my own printer/goals rather than submitting back to the greater good.

Hope the above helps re-iterate the importance of making it easier for those with limited time to feedback, as I am sure we also have something of value to contribute...

CraigRK Wrote:
-------------------------------------------------------
> I think this is a great idea and will be following
> it with interest.
>
> I have been following (and participating on the
> fringe) the RepRap movement for years now. As
> with many others, my personal commitments have
> meant that I have contributed less than I'd like.
>
> I would however like to add these points: I agree
> with the reasons why nophead says that GitHub is
> better than the Wiki, however I think as
> Traumfllug is saying, we need to resolve those
> issues, and ideally in a way that will suit
> novices or those with limited time.
>
> If things were simpler, I am pretty certain I
> would contribute more. Specifically the following
> quote is relevant.
>
>

Quote

> For example, uploading a patch to Github is a
> pretty complex procedure (fork, clone again, move
> the changes to the new repo, commit, push, submit
> a pull request).
>

>
> I have been a software developer and manager of
> software teams for over a decade now. I have many
> years of experience in software patching and code
> management, however my experience is in the
> Microsoft arena. I have been working on a
> Mendel90 and having joined GitHub and cloned the
> respository, I find it quite confusing trying to
> figure out how to commit and submit pull requests
> to nophead. Each time I have tried I have only
> have a short amount of time available, and have
> ended up spending most of the time progressing my
> own printer/goals rather than submitting back to
> the greater good.
>
> Hope the above helps re-iterate the importance of
> making it easier for those with limited time to
> feedback, as I am sure we also have something of
> value to contribute...

i too find github tedious, and give up after a while, i ended up writing a bash script which took care of uploading the problem being then is that i've had to abandon ubuntu for the time being so those bash scripts are useless now, these days even with the evils of thingiverse it's easier and quicker to stick stuff up there

---

-=( blog )=- -=( thingiverse )=- -=( 3Dindustries )=- -=( Aluhotend - mostly metal hotend)=--=( Facebook )=-

Traumflug Wrote:
-------------------------------------------------------
> Thanks for all the input.
>
>

Quote

There's absolutely no reason why you need
> to transfer any projects into github

>
> The reason is, if you want to track a project on
> Github, you have to actually have the project
> there.

Nope, you just use the issues tracker, you don't need to store any files there. The issues tracker is actually completely separate to git.

>
>

Quote

Obviously git presents a new tool to
> learn

>
> That's exactly ths point I try to avoid.

Completely missed the point. ANY new interface requires learning curve, whether it is hosted on our own wiki or elsewhere, therefore it is not an objection. As I said, if anyone cares to read, the Github issues tracker can be easily used by anyone with a web browser. You do not need to know any git commands.

>
>

Quote

You get a wiki with each Github project if
> you want to have pictures, etc.

>
> You do, and you end up with hundreds of separate
> wikis when promoting this.

Another pointless objection, we can still use our own wiki and track issues in github, it is not mutually exclusive. We could have a SINGLE github tracker for all RepRap bounties.

> Generally, please continue coming up with
> additional and different points of view. I have
> formed my opinion carefully, but this doesn't mean
> its right in every aspect. Perhaps I'm even on the
> entirely wrong track.

To be honest, I find it pretty pointless making suggestions. You have already a fixed idea of how you want to do it, and any alternative you just throw artificial roadblocks in the way, without trying to understand how an alternative would work, or even it seems reading what I actually wrote. If you have an uncertainty, ask "how would we do x?", rather than say "X would not work!".

We could have this system set up in minutes, but it seems you would rather all ramble on about an ideal system that will never happen! Maybe I should just go ahead and set up an example.

Quote

Nope, you just use the issues tracker, you don't need to store any files there.

I see. You want to create a project without uploading the files. That's indeed a possible solution. Missed this in the first post.

Perhaps together with wiki widgets for a simple user interface. The underlying structure would be pretty complex (Wiki -> Github -> Bountysource -> Github -> Wiki), but I guess it's doable.

Quote

Maybe I should just go ahead and set up an example.

This would be ideal, of course.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

About github, i use it myself, but i think it is too big, i keep that in mind. (I suppose i could try switch to gitorious or some other git hoster)

> Today is our quarterly reminder that Linus gave us a completely distributed VCS, so we stored all of our repos in a single point of failure

FTR: I quite like traumflugs idea.