pick the number of A's you want cool, by me.
dotrb Lightning Talk Friday Octobre 18th 2013
Hello my name is Ori Pekelman. I am OriPekelman everywhere (twitter/github/linked-in).
My blog is on http://blog.constellationmatrix.com
I am an independent software architect and I made myself a nice logo.
While researching this presentation I thought it would be cool of me to get some code going on.
This is an idea but in the Open Source world, talk is cheap and code is gold.
CODE === GOLD
So I thought, well my MVP just needs some image generation to make a nice badge
I kind of know Rails. So this should be easy peasy. Google please tell me what to do.
What happens next is the subject of this lighting talk.
So first let's thank Mark Evans for maintaining DragonFly !
Now, let's acknowledge we have a problem here.
We spend too much time worrying whether the stuff we use is or will be maintained.
We look for clues on hithub, how many active forks, how many open issues. Are pull requests being merged? We look at the Travis badge, at the CodeClimate one. Sometimes we LazyTweet. Sometimes we ask on StackExchange.
And some times we decide not use something, just out of fear.
But perhaps more importantly, we put undue, undeserved and unhelpful pressure on maintainers. When they don't react as fast as we want them to.
Put a badge on a github page saying if the repo is maintained or not. Use real metrics coming from github API (code climate / travis style). This should not take MORE work from the maintainer.
If there is a maintained fork and the original fork is no longer active give a link to the maintained fork (original maintainer just checks a box).
Help maintainers be better ones, with less pressure. Give them feedback. Allow maintainers to suggest they want someone to take over, accompany and ease the transition.
Poneys, Squirrels, Pirates, Babies and very cute cats.
This is basically around creating a "foundation style" governenship model for smaller projects, but without the hassle and the politics.
Put it in a box, as a service, lightweight, fun, only around decision making and transparency, not the discussions, they will happen somewhere else.
Make it into a place where we can thank maintainers. Even for those oft forgotten "small" projects
Forks (real ones) and Merges (real ones) are an important thing. It is time we had again clear semantics on this: this is a fork, that is going to be maintained as such. Might get merged back, or not.
Going AAAR is taking a pledge either to maintain or to do whatever is possible to help others maintain a project.