This past Monday we had a meeting to try and make some progress on
challenges we are having with our wikis and website. That meeting
and subsequent meetings are hard to summarize, so I'm going to skip
all the intermediate steps and try to describe where we are.
1. People brought up a number of issues related to the wiki/
website. You can see these in the notes from the meeting, which
I've attached to this message. We will be accounting for these as we
continue ahead
2. For the time being, I will be the temporary owner of the this
project until we can clarify our objectives enough to know whether we
want to hire someone or not. Because the website and wikis are the
point of entry for many different audiences, I am dubbing this the
"portal design" project.
3. I (and probably others) will spend some time talking to Deb
Richardson at Mozilla who is the person in charge of
developer.mozilla.org, which is a good example of a portal that works
well, looks good, and has a good amount of community contribution (to
the portal itself)
4. Coming up with a good design (and implementation plan) for the
portal requires a lot of information that is known to people in house
(and wouldn't be known to a new hire), particularly on the PPD
team. Mimi has already put up a wiki page <http://
wiki.osafoundation.org/bin/view/Journal/
OSAFInformationUsageScenarios>, asking for personal anecdotes
regarding the wiki/website. You can add your own commentary on the
wiki page (please sign it with your Wiki name), or you can reply up
to this message. I am going to work with the PPD team on additional
next actions.
INTERNET INFORMATION STRAIGHTENER-OUT PERSON
Attendees: Ted Leung, Jared Rhine, Lisa Dusseault, Mitch, Katie, Mimi, Pieter,
Reid Ellis, Matthew Eernisse
- Intro and goal of workshop (5m)
- Why are we here and what should we accomplish in this time?
- We are here to collaboratively create a job description - as a means of
coming to agreement about what kind of person we need to hire
- Topics which are not in scope of the workshop
- We are not here to think up possible solutions to our information
problems -- that is the job of the person we are hiring
- We are not making any decisions about the technologies that might be
used to solve our information problems - that is the job of the person we are
hiring
- We are not discussing/discussing organizational/reporting structure or
title
- Existing consensus (10m)
- What do we already agree on?
- There are important problems in the documentation/communications
area to be solved
- There is an open req for someone to improve the community's written
communications and documentation
- Someone must spend some of their day on pruning, cleaning,
organization
Additional resources/bandwidth beyond what we have in house are necessary
Problems:
1. wiki / website are not integrated
2. rapid recall of specific resources is difficult
3. discovery of resources is not possible beyond free-text keyword search -
no table of contents
4. resources are not reused often - e.g. syncml research
5. no table of contents
6. documents are monolithic - no transclusion
7. people are uncomfortable using wiki features
8. journal content is poorly discoverable
9. Different technologies provide different interfaces and pros/cons
Community member - we don't have a place to tell them where to go
Search engine has poor recall
- Screenshots
Recreation of already-existing resources
- Examples: syncml
Systematic search (finding all relevant entries) is difficult
Tone of many documents is "current", but quickly gets out of date
Categorization of content can change over time. "Reparenting" isn't often done.
We don't often distinguish between "points in time" documents and
"authoritative" documents (alternatively, our distinction isn't commonly
understood).
Nobody currently on point for maintenance and no broadly-stated goals to do so.
There's a need to be mindful of documenting the project itself and people doing
this in their spare time is not enough to solve the problems that we have.
We have differing audiences
Solutions:
Hire someone to own some pieces
Assign ownership to someone who is already here
Hard to tell whether a page is the current thinking or not
Lots of out of date information which appears as valuable as new info
Mitch Tenet: Find the expert
Tenet: Needs an owner. Not all projects do, but this one does.
Tenet: Focus on needs of new community members
Ted's problem overview:
- Leadership/ownership-level
- Information design and structure
- Organizational-level
- Technical-level
Types of usage:
- New community member ramping up
- Developer referencing planning and specification details
- Public getting an overview of the projects, work, and status
- Content producer building document over a period of time
- Content producer creating authoritative reference
- Enumeration of big open issues (10m) [ if you have additional issues, please
feel free to respond and add them ]
Questions of scope
specification docs,
non-public web sites
Interaction with
<http://producingoss.com/html-chunk/share-management.html#documentation-manager>
- Assembling the job description (30 m)
Recently Lisa Hanenberg wrote a good article about job descriptions
<http://managementcraft.typepad.com/management_craft/2006/01/how_do_we_defin_1.html>.
I've excerpted the major sections of her sample job posting here as a
proto-template that we can try to fill in
+ What we need most
+ What we don't want
+ The right fit
+ The details:
- Goals for the next 12 months for the XXXX include:
- Easy for new person to know what projects there are
- Make it possible for somebody new to figure out what each
project
is in 20 minutes
- Lower the barrier to entry for contributors to projects
- Make it easy to see the context of each content page
- Increase content usability even for experienced contributors
- Control growth of static content: via clear processes
- The toughest parts of this job:
- Technical skills and experiences we are seeking
- Seeing the patterns in information, write a TOC
- Ability to define, interview and see needs of information
users
- Technical ability to implement solution - wiki fu?
DHTML?CSS?
- Not necessarily principally a content creator
- Managerial/leadership skills this position requires
- What categories of work or specific work items are clearly in scope
for a new position?
- Structure and organization of public web sites/wikis
- Structure and organization of project web sites/wikis
- Coordination of volunteer content producers
- Facilitate OSAF staff contributing - via easy to use design, wiki or
other guidelines, etc.
- Hands on the keyboard: writing and pruning
- Review of existing discussion:
- Lisa's job description
- Ted's "project-oriented view" and 3 interview questions
- What can we agree is initially outside of scope for a new person?
Concerns
- Is it the right thing to hire somebody to manage this, unless we have the
resources to finish the job?
- Would we hire somebody to clean and maintain (and is that the justification
for a full-time position)? or do we spread that responsibility?
- Do we have the intellectual capital here now? Do we need expert guidance
to go any further?
- Are there people who have the skills we describe, who have done the job
we need -- including "open source" (ability to handle volunteer
contributions)?
- do we have sufficient resources to implement? Cannot assume mde will do
all the technical implementation work
Proposed:
- Person has background in project management
- Demonstrated experience in structuring and creation of documentation,
mailing lists and other communications mechanisms
-
- Consensus on success criteria (15m)
- How will the success of a new hire's work be judged?
- How will we know web-based documentation has gotten better?
- What skills, background, and characteristics are needed to support
the enumerated workflows?
- Organizational support (10m)
- What does OSAF need to do to set up any new hire in this space for
success?
- Team, tools, techniques
- Decisions restatement (10m)
- What decisions have been reached?
Next steps
- post notes of this workshop to a venue for additional comment/ideas
- working group to drive this - Ted, Sheila, Pieter, Katie
- review of job description by dria or similar individual
- time driven goals for a working group
- will consult w/ Cosmo/Scooby projects
- Ted replaces his headset battery :)
=============================================================================================================================
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
I went as far as documenting what we discussed at our offsite, as well as some
thoughts from googling various job titles and reading job descriptions. I
found an entire chapter on Information Architecture, from an O'Reilly book,
online -- <http://www.oreilly.com/catalog/infotecture/chapter/ch02.html>.
Best summary I found: "The primary responsibility of this position is to apply
user-centered research and design skills to organize information in ways that
are meaningful and useful to our stakeholders."
Best analogy I thought of: this person would be to OSAF tech writing and Wiki
content production what Aparna is to OSAF QA -- manager, coordinator, decision
maker, expert.
Possible Job titles:
- Information Architect: This shades into Interaction Designer since it's
usually Web site focused -- here's a good analysis
<http://www.stcsig.org/id/id_employment.htm>.
- Technical Writer, although sometimes the job description matches what we
want, doesn't generally imply the level of organization and coordination we
need <http://www.jobprofiles.org/bustechwriter.htm>.
- Technical Writer Project Lead -- doesn't sound as cool as Information
Architect
- User Education? Nixed -- this was a MS term and not generally understood
- Web Content Administrator?
<http://www.salarysource.com/description2.cfm?cdkey=8#356>
- Documentation Producer? this implies too much page layout and book cover
design
Responsibilities (notes from our offsite, possibly not complete)
- Provide high-level organization and structure for OSAF's Wiki, Web,
user/admin documentation and other written materials: what goes where, how to
find, summarize, showcase, maintain and retire material.
- Support community contributions to OSAF's written materials, and possibly
even support new developers (like Aparna coordinates QA)
- Later in product cycle: Contribute to Chandler "Help" files, menus, tool
tips and other text in the application
- Describe APIs at a high level
- Edit contributed material
- Identify missing pieces of documentation and coordinate to get them filled in
- Identify audience needs and audience level to help review appropriateness of
documentation material and develop doc guidelines
Some examples of what they might do day-to-day
- Move Wiki pages from one area to another (e.g. from Projects to Journal or
Trash)
- Track what Web and Wiki pages are read the most and keep those aggressively
up-to-date
- Do copy-edit and higher-level content review on anything from my
presentations to API documents written by full-time or volunteer developers --
mostly an ad-hoc basis as these things are submitted
- Answer questions from content contributors about what a reader of a given
document might or might not know
- Answer questions from volunteers on where to find some info...
- Work on very high-level documents like "1.0 Vision" -- in other words,
actually write content sometimes (like Aparna definitely does actual testing)
- Use information from bugzilla and PM to write release readme?
What we're not hiring
- Somebody to write all documentation in lieu of volunteers/devs!
- A community wrangler or forum administrator?
Questions:
- Is this a full-time job?
- What's the generally desired education? Master in Library Science?
Information Architecture and Web development?
- What kind of technical expertise would we need? Somebody capable of being a
tech writer in this field?
- Is there too much overlap between Information Architect and Interaction
Designer? (Often these two titles are combined in one job description). Note
that we'll have two Interaction Designers starting January.
Comments on this are most welcome. I'll try to make more progress in a week or
in the new year depending on the feedback
Lisa
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Thanks for following up on this. Rather than look at this from the
perspective of what job description do we need, I want to look at this in
terms of the problems that we need a to solve. From there, the type of skills
that we need ought to fall out. Here's a (probably incomplete) list of the
problems that we need to solve, in decreasing order of priority.
=== Inability to build community (user and developer) due to poor
communications, including:
- Poorly organized website/wiki
- Split website/wiki
- Wiki is hard to search, IT doesn't have the bandwidth to do upgrades on
the software
- Wiki is aimed at the wrong audience
Short - mid term projects that I see:
* Co-ordinate w/ Pieter re: branding exercise for chandler, cosmo, scooby
* Refine chandler.osafoundation.org site -
- look at how the site is working now, figure out how to improve it,
- make it easier to update
- figure out what we need to preserve from existing wiki
* Adopt the chandler.osafoundation.org "methodology" on cosmo and scooby
=== Inability to motivate users/developers because we are not clearly
communicating our product vision
- This is partially a result of the product management piece that we touched
on at this weeks ops meeting
Short - mid term projects that I see:
* Refine / combine our "Vision" documentation
* Add system/ecosystem point of view to these documents, also do documents
for Cosmo and Scooby
* Provide timely public status updates of where we are along the way
=== Inadequate developer documentation
- at the system level
- at the API level
- poor co-ordination between web-site and system level documentation and API
documentation
- not even started for cosmo and scooby
Short - mid term projects that I see:
* work with feedback on 0.6 developer documentation to improve and expand
existing docs
* devise developer platform documentation roadmap as a part of developer
platform roadmap from here to 1.0
* create documents on that roadmap
=== Inability to integrate non-staff contributions to documentation (web,
helpfiles, etc)
- We don't actually have this problem yet.
Short - mid term projects that I see:
* This is a back burner task
With regards to hiring, it is hard to come up with an exact job title for a
position because this kind of position is relatively rare. As you noted it's a
mix of IA, Tech Writer, Community Builder, Developer Technical Support and
others. I think we are going to have to live with that ambiguity rather than
be shoehorned into an "industry standard" job description.
I would be ecstatic if we could find someone like Deb Richardson
<http://developer.mozilla.org/en/docs/User:Dria>, who has overseen
developer.mozilla.org.
That site is a great example of what the developer oriented parts of our
websites ought to look like. They've even managed to do it using a wiki.
Ted
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Philippe
I like Ted's bottom-up approach better myself. At least, I can see what we're
asking this person to do. That being said, I see no contradiction with what
Lisa wrote really (it fits her "Best Summary") except that it eliminates some
of her proposals for job title.
Is that a full time job? I'd say it is for 6 months (may be more) looking at
Ted's list. Beyond that, it should be maintenance and tweaks and we may or may
not have other needs that can be handled by this person to justify the
headcount. What about starting with a 6 months full time contract?
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ted's
Here are 3 questions that I want the new hire to answer
1) What are specific things that are wrong with OSAF's website and wiki? (it
sucks is not a good enough answer)
2) Why (or in what specific ways) are these problems hindering OSAF's goals?
3) What specific steps would you take to improve the website and wiki? Which
people (job functions or people) would you need to work with in order to do
this?
----
Ted Leung Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
