My participation on the Civi doc team this time around has not been as robust as I hoped it would be at this point. I just haven't had the time I'd like to devote to it.
However, I have managed to get some basic stuff done. After several email exchanges with Michael, the coordinator of the documentation community, I agreed to work on marketing copy in general and the main project website in particular. The Civi community (as conveyed to me by Michael and Dave, another member of the core team) wants to improve Civi's image as a professional project and make it easier for potential users to figure out if Civi is a good solution for them.
As you can see from looking at the site, there are a lot of problems and a lot of low-hanging fruit. The page is cluttered and busy and the navigation is duplicative and confusing. A lot of the copy is clunkily written and even contains a not-insignificant number of grammatical errors.
The first thing I did was look at a blog post from a community member who had already put some thought into site improvements. The doc coordinator also identified some specific pages he thought needed attention. After I read those over, I did my own content audit and identified some further issues. I compiled the results into a spreadsheet that can easily be shared with other contributors. (Interestingly, Michael specifically did not want me to enter anything into the issue tracker, because he first wanted to ensure that there was someone to assign the issues to (and, I suspect, he wanted to approve my proposed changes first). I assigned myself to most of the issues and I intend to chip away at them over the course of the rest of the semester.
The two other things I've done so far are: 1) write some descriptive front-page copy and 2) make a proposal for improved site navigation. Michael and I are slowly but surely discussing the proposal through Google Doc comments. I will soon start producing more proposed copy, working off my spreadsheet (which has since been enhanced with feedback from a recent CiviCon London participant). Also on the agenda is to wrap up a conversation Michael and I were having about process, and whether I should get login information to the site's CMS or whether I should submit copy to him. Of course I prefer to have my own login (which would also make it easier for me to answer some of the outstanding questions identified in the spreadsheet), but I don't want to push.
As far as how my experience fits in with our readings, it's interesting to note that the infrastructure suggested by Fogel is in place for the Civi documentation team, but it is sparsely used. Partly I think this is become some tools are much better suited to development than to the production of text, but I also think it's because the documentation side of the project is newer and less far along in its organizational development. The tyranny of structurelessness also seems important, as I have definitely been able to jump in and start working much more quickly because I have a previously established relationship with the project. While it's possible that I could have gotten where I am by reading up on the site and sending some cold emails, it's equally possible that I'd have gotten nowhere with that approach. However, I see this more as a tyranny of bad information architecture than a social problem akin to what Jo Freeman describes. (As noted in my first blog post, the meta documentation for Civi is in sorry shape.)