 |

 |
|
 |
 |
 |
 |
|
 |
 |
Okay now that F9 is out the door, and before I've voted out of office, its time to take another stab at a discussion about building and strengthening the abilities of role based SIGs inside the Fedora projects moving forward. I've come to picture the work the Fedora project needs to do as structured in terms of two types of communities (I have to credit Greg for some of the refinement on the image from the last round of discussion about this a few months back). One such type of community I would name "Subprojects". A subproject would be a group of peers who are doing roughly the same things, and could be considered a guild for a particular type of skilled labor. The other type of community I would name "Special Interest Groups" (SIGS), and each SIG would encompass all roles from users to developers that are needed to sustain the growth of software usage and development for a particular purpose. Common tasks or experience define the membership of Subproject Common interests but different tasks and experience define the membership of a role-based SIG. SIG roles would map directly to subprojects. The idea being that people from different SIGS who are doing the same sort of tasks can establish best practices through discussion in the subprojects associated with that role. For example we'd have a packaging subproject, and each SIG should have members filling the package maintainer role who were also participating in the packaging subproject to learn and refine best practices. Same goes for documentors, triagers and so-on. But its not a one-to-one mapping. There would be needed Subprojects which don't necessarily map to a common SIG role, but they would still exist to get specific work done or to establish a peer group of experts. I would hold up our infrastructure,translation and marketing teams as an example of this type of Subproject construct, a Resource Subproject. They key idea is that for the role-based SIGs idea I am putting forward, we turn the SIG concept deliberately into a construct that encourages direct user participation, so that SIGs can more easily recruit for their own expanding workforce needs their own by connecting with users who are already interested in and using the software in the scope of the SIG. Experienced, veteren SIG members take on the role of mentoring and sponsoring new recruits.. and the SIG becomes a self-sustaining community with the goal of growing the capabilities of open software for a particular area of interest. It is my very fervent belief that we need to build a recruitment and retention program inside of the Fedora Project that encourages enthusiastic users to become active contributors, and I think the role-based SIG construct has the best potential of doing that.. we just have to shake-up and tighten-up what we mean we we talk about a SIG. And that is exactly what my role-based approach to SIG building is meant to do. Okay so I think that was close enough to a thousand words. Here's the updated cartoon diagram of what I mean when I'm talking about role-based SIGs:  -jef
|
 |
 |
 |
 |
|
 |
 |








 |
|
 |
 |
 |
 |
|
 |
 |
I sort of agree with what Chris has said about Miro... and I sort of completely and utterly disagree at the same time. We have a real problem in how we apply different definitions of "open" and "free" as it comes to content and code. It's a really painful problem...it keeps me up at night. I personally wouldn't call most of the content Chris describes as "open" nor would I call it "free"... I'd call it "consumable". I'm certainly not allowed to redistribute or reuse the bulk of that material to generate my own content. I doubt that I can legally take wired science video and make use of it beyond simple viewing. The PBS website's default rules for hosted content certainly doesn't guarantee that sort of "freedom" to be as a user of that content: http://www.pbs.org/aboutsite/aboutsite_rules.htmlIt's the same sort of problem that's lingering over Creative Commons, concerning the confusion over what CC licensed really means. People keep running afoul of the restrictions on use for some CC material because those restrictions restrict freedoms that we've come to expect for "open" and "free" code. The differences between code and content will continue to be confusing, especially if our prominent proponents who straddle both areas of digital works don't make it a point to use terminology consistently. That being said, it's great that Miro is a platform for getting access to "consumable" content. Its not so great that for the vast majority of that content... you have to be a "consumer" of encumbered software too. In a very fundamental way Miro has punted the hard problem in the space... encumbered video playback. The technology that Miro represents is built assuming that Miro users have legal access to the necessary technology to render the video that Miro organizes. For users of a commercial operating system, that assumption is easily met.. but it's not an assumption based on "openness" or "freeness" as we have come to apply them to software. So again, i have issues with using these words in association with the technology. But Chris is right, Miro as an organization should be applauded for taking direct action and solving the problem they care about. Regardless of whether or not I think Chris should parse his words more careful concerning "open" and "free", Miro as a group is out there doing work and making things marginally better in a space they care about. So the question is.. for those of us who care about truly "free" and "open" content, through its entire lifespan from creation to consumption, and then re-use.... what direct actions can we take to make things marginally better? For those of us in the Fedora project specifically, what are we doing to make "open" content generation feasible? What are we doing to make consumption of "open" content feasible? And just as importantly who among us has the talent and the ability to create compelling and truely "open" video content that can be viewed in applications like Miro? -jef
|
 |
 |
 |
 |
|
 |
 |




|
 |
|