Define a clear git branching model

Jonne, is there any reason to keep them after the merge? Personally I cannot see any. I smell a proposal :)

Hm maybe so that you can reopen a pull request if the merge got reverted?

While I could see potential for keeping old branches around, the problem is that they're mostly kept around indefinitely, and that creates a fair amount of clutter.

Honestly, a time limit of a few weeks to a month sounds reasonable. It's enough time to revert back a feature or bad fix, without cluttering things up too much in the long run.

The problem is if they are not cleared straight after merging - who will clear them later? :P

I dunno, honestly I wouldn't mind regularly pruning away branches that have been merged and inactive for more than a month.

No harm done if some branches are not cleaned ;)

I just forked the project, pulled my fork, fixed a bug, git commit -a'd, git push'd, and made a pull request. Should I have forked and then branched from my fork?

Hm well, yes, you should've followed https://github.com/diaspora/diaspora/wiki/Git-Workflow ;)
Btw. looks like we need to rework that document in 8 days

Well, https://github.com/diaspora/diaspora/wiki/Git-Workflow is pretty clear. :) Getting set up that way now.

Less clutter will come also with better communication I guess. What direction it goes, the core , the modules maybe, and so on. I.e. I get courage to delete a branch if I know my wishes are perceived in the dev community. - Just a thought, hope it was clear what I mean.