On Tue, Oct 14, 2008 at 9:23 AM, fairchild <[EMAIL PROTECTED]>wrote: > > 2 cents more: > > > Some ideas: > > - should that be part of merbunity? github? or a separated site? > Hosting the slices on github. > Seperate site to deal with all the discussion ratings, etc, It > definitley is nice to have one central location to browse thru what's > available in a friendly manner. > > > - what features are you thinking of? ratings? comments? > a.) thumb up or down woudl be nice > b.) could have a flag for "passes public specs" > c.) comments or forum would be great > > > - naming conventions like merb-slice_slice_name_here ? > merb_slice_slicename would be nice. Would be especially nice if > reponame matched slicename. > > The drive home we were talking about this and would be glad to help > out with a merbslices site. > > Cheers, > ~Michael > > >
Hey guys just got home :) I've been talking to fabien and we've been thinking of this kind of setup: It should be a seperate site. There's too much functionality for it to be a direct part of merbunity and I don't think it would be best served this way. The two functions are quite different. We have a domain for it slicehub.com where we think it should go. As far as how to construct the site, I think the major (starting) features should be: Description (detail page), Team, Wiki, Versioning (Each slice gets one of each) Also different types of markup should be allowed. The secondary features that I think would be in the ball park would be: gem server integration, voting system that takes into account current trends not just overall votes, public spec behavior (shame if it uses non public api, fails etc) It would be nice if we could implement the main functionality as a slice or slices but I'm keen to just get something awesome happening ;) Yehuda has created a repository for the site at http://github.com/wycats/slicehub/tree/master. I've generated a fresh application for it and put it up there. Please if you'd like to work on it, lets get a page up on the wiki and start getting the main features up on there. People can claim what they want to do and work in a fork that we can then pull into the main repo. Please no mocks for specs... For controller specs, no dispatch_to, get, put, post, delete specs. Lets stick with the request helper for all controller/view/router specs. What do you guys think? ~ Daniel --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
