[of-dev] towards openFrameworks "teams" and "projects"
kyle at kylemcdonald.net
Tue Jan 6 13:05:46 PST 2015
in the past, projects have started by people creating private repos that
either fork OF or start something new completely. then that project is
managed with its own issue tracking, and eventually merged with a single
in the future, i'd like to see more branches of the openframeworks repo, or
even repos under the openframeworks organization, but only because i want
people to feel that the work they're doing is "official" and has our
for smaller projects that don't demand an entire repo or branch, a
combination of 1 and 3 (tags plus main/sub issues) are great. this is the
way apothecary is working right now, even though it started as its own
repo. checklists have also been working well.
i'd like to avoid the hackpad solution, because it's harder to keep track
of (only because it's not in the same place as the issues, and you can't
see a progress bar on checklists), but for the ofDoc roadmap it hasn't been
in short: whatever works, but everyone should feel free to use the
On Sun, Jan 4, 2015 at 12:18 PM, Elliot Woods <elliot at kimchiandchips.com>
> Hey Kyle, all
> Thank you for continuing to spend time to improve the way the group
> coordinates and communicates.
> This development is welcome and I look forwards to the 'project basis'
> development getting strengthened.
> What is the best way to centrally coordinate a project?, e.g.:
> 1. A main github issue, with subissues
> 2. A hackpad, with a number of github issues
> 3. A github tag, shared by a set of github issues
> the most automated is 3.
> i think 1 makes the most sense given the 'energy drive' around a project
> (including the conversations which tail-off in different directions)
> On 30 December 2014 at 19:16, Kyle McDonald <kyle at kylemcdonald.net> wrote:
>> hi everyone,
>> - - -- short version
>> we're moving away from the "section leader" role, towards "teams" and
>> - teams: one or more people generally interested in helping with a
>> section (think "android")
>> - projects: a specific effort with goals and timeline (this "c++11" or
>> how is this different than what we're doing now? it's not! most of the
>> community structure for openFrameworks is descriptive (we try to find a way
>> to describe the best parts of what is naturally happening) rather then
>> prescriptive (telling people how to collaborate). and hopefully with better
>> understanding, we can collaborate more effectively.
>> - - -- long version
>> back in december 2009, openFrameworks was moved from a private svn to
>> github. two years later, in december 2011, we introduced the idea of
>> "section leaders" to the openFrameworks community  and later we put some
>> documents on the wiki to try and formalize the contribution process 
>> three years later, we've learned a lot about what does and doesn't work
>> when a distributed group of volunteers comes together to develop a creative
>> coding toolkit.
>> the model we've been using until now is "section leaders". in theory, a
>> section leader is someone who has interest and possibly expertise in
>> guiding a subsection of openFrameworks, anything from "documentation" to
>> "outreach" or "iOS". they have the access to any accounts or repositories
>> they need, freedom (within guidelines) to commit and merge changes, and a
>> responsibility to keep up with the discussion on any related features and
>> for a couple people this model has worked really well, but for everyone
>> else there has been some problems with this approach:
>> - the exact responsibilities are ambiguous, some people feel guilty they
>> aren't "leading" enough
>> - there is no clear term, or endpoint, or way to "finish" a job as a
>> section leader, and a stigma around leaving 
>> - having just one leader per section creates an unfair burden for that
>> person in a project as active as openFrameworks
>> - people with interests already covered by a section leader avoid taking
>> initiative when they think they might be stepping on someone else's feet 
>> with these things in mind, i started a discussion with zach, theo, and
>> arturo in november about another direction to go. we spoke with all the
>> section leaders, and it seems like the right move: we're going to break the
>> "section leader" role into "teams" and "projects". here's an initial
>> - teams are meant to be very fluid. they're focused on a section. people
>> can be in as many teams as they think they can contribute to. you will have
>> access to any accounts or repos you need, but are also expected to
>> contribute to discussions, and remove yourself from the team if you don't
>> expect to be able to contribute for a while. we're happy to add and remove
>> anyone who has interest, and would hope team members can mentor each other.
>> github also has a great mechanism allowing you to @mention teams by saying
>> (for example) @openframeworks/ios and everyone on that team gets an email.
>> the more we use this, the less it has to be about any specific person, and
>> it can be more about anyone who has time.
>> - projects are just a name for things like linux arm, c++11, 64-bit,
>> halfdanj's "docs" work, the current apothecary drive for complete coverage,
>> workergnome's multilingual work, etc. projects usually form when one or
>> more people  show interest in developing a complex new feature or taking
>> OF in some new direction. it's almost always that this is where the real
>> "leadership" emerges, and people make plans, goals, timelines, etc. we want
>> to recognize this more "officially", and keep up good communication to keep
>> these projects flowing :)
>> with that said, the next steps are:
>> 0. does this make sense? is this a more accurate description of what's
>> happening, and a useful direction to head?
>> 1. we need to fill out the wiki with slight revisions to the
>> "Code-Contribution-Workflow" and "Pull-Request-Review-Procedure" pages to
>> change the language.
>> 2. a bunch of people are already making regular contributions to
>> different sections, but aren't necessarily on a team yet. we'd like to add
>> you! please get in touch :)
>> 3. we should change the OF website to reflect this new structure. i've
>> attached a screenshot of what i imagine the "contributors" section might
>> look like. it's mostly generated by a script pulling from github, i
>> sincerely apologize if i've overlooked something. i'd love some feedback
>> before i merge the pr! 
>> thanks again to everyone who continues to make openFrameworks awesome!
>>  http://forum.openframeworks.cc/t/call-for-leaders/8391
>>  stigma about leaving is a big problem in oss in general, and
>> something we should be careful to avoid with OF. some great notes in this
>> the fact that some people have left regular OF involvement and are open
>> about saying why makes me think OF isn't a toxic community
>>  this issue may seem minor at first, but when there is any hesitation
>> about contribution, then only the people who feel most entitled and
>> aggressive about their contributions will be the ones contributing, in turn
>> creating an unwelcome culture.
>>  projects are often the result of one person having an intense
>> interest in something, but the project lead sometimes changes over the
>> course of a project
>>  https://github.com/openframeworks/ofSite/pull/318
>> of-dev mailing list
>> of-dev at dev.openframeworks.cc
> Elliot Woods
> elliot <elliot at kimchiandchips.com>@KimchiAndChips.com
> UK : +447944977628
> KR : +821034458086
> of-dev mailing list
> of-dev at dev.openframeworks.cc
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the of-dev