Session Notes - Summer of Content
This session was held toward the end of the day, and many now familiar faces came by to discussion content and the state of documentation in FLOSS. This page presents a (now) organized view of that discussion in the form of bullet points. Anyone who was there can add additional content to give more meat to these points.
One goal from this discussion was to decide:
- Should we propose a new content or documentation-focused event for Google to sponsor?
- What form should that take?
A decision was reached that, yes, we do want to propose an overarching Summer of Content, that focuses on bringing content into the communities that benefits open source. Examples are documentation, screencasts, art ... in fact, one of the goals is to invite media artists to contribute not just new content but new ideas about open content.
Need for Open Content
- Open content and redefining developer as a way to get people really involved
- There are actual needs that use non-coders to make software better
- Hard to get people involved/interested - why?
Getting People Involved
Refer to SessionNotes/RewardingContributors for more ideas on how to give people incentive and get them continously involved.
- Meme: "Developers don't enjoy writing documentation"
- Why?
- Gets you out of the coding zone
- Is this really true?
- No
- Some use this as a way to get onto a project
- Let them use their tool of preference
- Make documentation part of the toolchain and existing processes
- Yes
- Loss of zone
- Can't make someone do it
- No
- Why?
- Value in having a core documentation team
- Can be stand alone or part of the development team itself
- At least have a leader
- Owns the tools and process
- How do you parse a bunch of documentation applications?
- Get academia to support Summer of Documentation
- Teachers helping their students to apply
Best Documentation - How?
- Doxengen and friends only has use if you know what you are looking for
- Not useful for new users
- "Best Documentation"
- Covers everything, in depth
- Takes team of hundreds of people
Or does it? - Time to apply a little open source methodology
FLOSS can supply teams of thousands
- How to make content like code
- FLOSS methodology
- Need processes similar to what works on code side
- Self-reflective tutorials
E.g. self-building, correct example using DocBook XML
- How Wikis can work
- Stub-effect - create stub pages or pointers that others can work on and easily contribute to the whole.
- Feedback loop, like commits list
Example - http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats
Content is a gateway drug to open source
- Provide clear path to grow and change role
Licenses
- One license that can cover them all?
- Creative Commons is made to cover "any media"
- Is moving toward more open (in response to questions about commercial use)
- Need to research about NO WARRANTY clauses, esp. for technical documentation (which has a risk involved)
- Creative Commons is made to cover "any media"
Summer of Content Proposal
- One proposal
- Focus is on content that supports FLOSS projects (criteria)
- Content is all media
- Separate project v. subsumed into existing SoC
- Talk with Chris about this part
- Need internal advocate at Google
- A writing group?
- Need internal advocate at Google
- Advocate outside of Google?
- Talk with Chris about this part
- Who is the audience/pool of contributors
- Students, as a start
- Stick to technical content
- Start with this, see where to expand
Proposal Team
- Proposal co-leads
- Proposers
Comments
ErichSchubert says:
I didn't have time to attend this session.
It's not just about documentation; IMHO we should also encourage artists (especially graphics and sound artists) to contribute more to the opensource world with copyleft licenses as a means to make their work publicly known. There are a few artists doing a great job on e.g. Tango, but there are just few of them. Some projects, especially games, could really use some more artwork/sound contributors; and these contributions need to be covered by a clean license.
For example, the Debian package of Enigma has its title music removed, because it lacks a DFSG-free license. There were some artists interested in providing e.g. improved sounds, but their use would be tied to Enigma, which again isn't DFSG-free.
