Mindshare is not a perfect metric for judging worthiness - consider plurality voting for example.
Git is a fine and powerful tool but it is complicated and quite counter intuitive in some ways. (fyi I've used rcs, cvs, svn, designsync, bitkeeper, monotone, darcs, mercurial, bazaar and fossil). My recommendation would be fossil. Although one of the youngest of the bunch you get a wiki, tickets and the easiest install and setup on windows and linux (and MacOS I believe) available and a simple but adequately powerful usage model. A nice writeup that captures my sentiments can be found here: http://sheddingbikes.com/posts/1276624594.html Anyone who wants to try fossil (for open source code) but needs it to be hosted can send me a request with the project name and I'll set you up an online server on my host - no cost to EM members :) . Your repo would be at http://www.kiatoa.com/fossils/<yourpoject> (here is one of my fossil repositories http://www.kiatoa.com/fossils/opensrc). I plan on putting together a minimal github like site at that location. All this begs a question, what voting system makes the best sense when the voters have differing levels of competency related to the vote? Matt -=- On Fri, 2011-05-06 at 14:05 -0500, Duane Johnson wrote: > Git and GitHub has the largest mindshare among open source developers > that I am aware of (I come from the open source dev community, not > academia). If you want to be discovered or collaborate, I recommend > that route. > > Duane > > On May 6, 2011, at 1:19 PM, Brian Olson <[email protected]> wrote: > > > > > I counter-recommend git. I don't like it. If you like the new > > 'distributed version control' system style, I recommend Mercurial. > > code.google.com also supports mercurial. > > > > > > My own election simulator is also up on google code, also with > > subversion. > > > > > > It's kinda hidden inside my project for multi-language (C/Java/perl) > > election method implementation library. > > > > > > http://code.google.com/p/voteutil/ > > > > > > http://code.google.com/p/voteutil/source/browse/#svn%2Fsim_one_seat > > > > On May 6, 2011, at 8:29 AM, Jameson Quinn wrote: > > > > > I recommend you put it up on GitHub. Git handles versioning and > > > source control for you, and github is a good place for people who > > > want to suggest code changes to do it directly, so it's easy for > > > you to just accept or reject those suggestions. If you don't want > > > to have to learn Git's command-line interface, there are a few gui > > > tools: you can use git-cola for making checkins, and giggle or > > > gitg for looking at the history of checkins. > > > > > > 2011/5/6 Kristofer Munsterhjelm <[email protected]> > > > Quite some time ago, I rewrote and expanded the > > > singlewinner part of my > > > election method analysis program, mainly to add a cache to > > > make X,,Y and X//Y methods very fast if results for base > > > methods and sets X and Y had been calculated earlier -- > > > and to only calculate the pairwise matrix one instead of > > > 200 times if I were to find the results of 200 Condorcet > > > methods. > > > > > > The last week or so, I've been cleaning up that code, and > > > a version is > > > up on Google Code at http://preview.tinyurl.com/5rd5krp . > > > It's only > > > tested on Linux, has some known bugs, and the actual > > > structure isn't > > > documented apart from comments, but there it is. > > > > > > I'll probably continue working on it now that I know how > > > versioning > > > works :-) If anyone has any questions or want to add to > > > it, go ahead and reply! > > > > > > ---- > > > Election-Methods mailing list - see > > > http://electorama.com/em for list info > > > > > > ---- > > > Election-Methods mailing list - see http://electorama.com/em for > > > list info > > > > > > ---- > > Election-Methods mailing list - see http://electorama.com/em for > > list info > > > ---- > Election-Methods mailing list - see http://electorama.com/em for list info ---- Election-Methods mailing list - see http://electorama.com/em for list info
