Hackpads are smart collaborative documents. .

Gene Kogan

692 days ago
Unfiled. Edited by Gene Kogan , Kyle McDonald , Matt Felsen 692 days ago
IRC Meetup May 3, 2015
 
 
  1. ofzach: ofBook
Kyle M
  1. waiting for golan and elliot at this point, then we will launch and integrate with the site
  1. no current plans for printed material, but we want to do it eventually. lulu and amazon are the main considerations.
  1. ofzach, nongio: project generator
  1. looking for more eyes on https://github.com/ofZach/ofxCef
  1. trying to get the project generator command line tool built as a non-OF app (.app is annoying to work with from the command line)
  1. arturo: what's the plan with glm?
  1. Projects on hiatus? Need to find funding? Or new contributors?
  1. genekogan: idea for a "templates" project based on this repo
  1. could work really well as tutorials for understanding more stuff outside the OF core
  1. possible venues: tutorials page, creative apps, OF blog
  1. workergnome: multilingual site
  1. halfdanj: documentation
  1. dantheman: testing OF / buildbot
  1. general thoughts
  1. there is a sort of tradeoff between individuals and teams when working on these projects. individuals are good at taking control and getting things done, teams can last for longer.
  1. projects with clear "solutions" get done more efficiently than the more vague "do good for the community" projects.
  1. documentation of work in progress helps create accountability, interest, and the ability for others to pick up where someone left off.
  1. maybe working on slack channels for documenting progress on projects?
  1. bilderbuchi and issues
  1. 0.9.0
 
  1. Zach Lieberman mentioned at Resonate: the possibility of moving to a regular release cycle with a short duration starting with 0.9.0, for example, every 3 months.
Zach L
  • actually, I was suggesting something very short, like every 6 weeks (I think shorter and automated is better -- even having it fixed on the calendar) .  
Kyle M
  • This sounds great, and it could be a good change from our current milestone-based "release when it's ready" model. We would need to maintain development branches for big changes and only merge to master when a branch is ready. This approach would fail if we didn't merge to master or make changes against master often enough.
  1. Git Large File Storage for libraries?
  1. shallow clones might help fix this problem
  1. apothecary is the real answer in the end
  1. Community
 
 

Contact Support



Please check out our How-to Guide and FAQ first to see if your question is already answered! :)

If you have a feature request, please add it to this pad. Thanks!


Log in / Sign up