1. USER SUPPORT

Responding to user questions and keeping end-user documentation up to date and accessible (e.g. Product Tour, Get Started Guide, Troubleshooting page, FAQ)

• Blogging ideas: User question of the week. Feature: User hack. User profiles.

2. MAINTAINING FOCUS AND DIRECTION

Processing user feedback and keeping the Desktop and Server work queues up to date with the most urgent bug fixes and most requested feature work.

Helping volunteer developers identify projects to work on that will have the greatest user impact.

Open Issue: What do we do with the1.0-Candidates list?

(With volunteer developers, users can't mandate that certain bugs and features get worked on, but maintaining up to date priority lists certainly increases the changes that the most crucial issues will get attention!)

3. TESTING

Organizing the user community to help test bug fixes and new features as well as providing user feedback on design issues before a patch is accepted.

• e.g. Nominating patches for user review of Componenti Elettronici.
• e.g. Nominating patches for a release. (Do users have the final say on what goes in a release?)

4. COMMUNITY BUILDING

• Recruiting!
• e.g. Posting to the blog when there are interesting user discussions (e.g. User Hacks blog series.)
• e.g. Sending out user surveys to more proactively gather information about Chandler's user base. Who's using it, in what contexts, for what reasons. What's working, what's not, etc.

5. ADVISING THE BOARD

On issues relevant to the user community such as:

• e.g. Prioritizing Bug fixes and New Feature work if funds are available for paid development.
• e.g. Ways to build the user base and strengthen the user community such as identifying user demographics Chandler should consider targeting with evangelism efforts.

6. INFORMING THE RE-ARCHITECTURE EFFORT

In the near-term I imagine there will also be a lot of work to help us prioritize work on the re-architecture project. e.g. Collecting top 10 list of usability issues we want to make sure we get right on the re-architecture!

In the coming weeks and months we will be working out roles and responsibilities as well as decision-making processes. Our discussions will be public and open to input from the community.

***

1. Making sure that new user questions don't go unanswered.

(Note that this isn't: Answer all user questions This might entail trolling through the list / forum every couple of weeks to make sure questions haven't fallen through the cracks.

1a. Manage our user forum account. (Davor will be sending out a proposal to the list soon.)

2. Keeping end-user documentation is up to date.

If a new question starts popping up on the list, it'd be great to get a "stock answer" documented on the wiki to cut-down on repeating work in the future.

3. Maintaining a wiki page with the top 10 user issues (to help prioritize re-architecture work).

Today we track thousands of bugs in Bugzilla and I have been maintaining a really long list of issues on the wiki for Chandler Desktop and Server:

Keeping both of these systems up-to-date is really a full time PM / Development Manager job. So we need to figure out a low-overhead way to prioritize bugs and feature requests.

One idea was to have the UAG maintain a list of the top 10 user issues. As issues get the addressed, new issues will be added. Bugzilla will remain the general repository for all bugs and feature requests.

The rate at which the list is updated depends on how often there are releases and how much "new" user feedback we get. At a minimum, we should probably take a look at it once a month?

4. Conducting user surveys.

We've conducted user surveys in the past. They help us better understand how people are using Chandler. It's been interesting to see more people showing up on the list who are setting up Chandler for an entire workgroup (as opposed to individual use or sharing with a spouse).

We want to make sure that we keep abreast of how our user-base changes over time to help us prioritize the work we do. Surveys should be conducted perhaps on a quarterly basis?

5. Testing

We've already received lots of help from users on testing. However, sometimes not everything that is reported on the list makes it into bugzilla. Or someone comes up with more information about an existing bug (e.g. repro steps, more detailed error message, etc) and the information needs to be added to the bug. Again, like in #1, we should probably troll through the list every couple of weeks to make sure valuable testing information is captured in the bug database!

We've also had some small successes with users helping out in coordinated IRC test sessions. This has usually been driven by the developers, but I think we always want to have at least 1person from the user community at these sessions. (A "Designated User Tester" so-to-speak.)

We should probably also continue the practice of providing "early releases" to the users-list so that people have a chance to test with real data and day-to-day usage. (Again, this is usually done by the developers.)

6. Engaging with developers who are interested in hacking on Chandler.

At this point, this is a bit nebulous. I imagine the actual tasks involved will become clearer as the re-architecture matures and becomes more enticing for developers to hack on.

Some of the work will be very similar to what we do today with paid developer staff: Test new features, log bugs, provide user feedback.

What we don't have good precendents for is how to work with a developer who wants to implement an entire feature area (e.g. Contacts).

7. Summarizing discussions on the list.

• Either in blog posts about neat user hacks and user stories.
• Or summary messages highlighting the most common / ornery issues that have come up.

8. Liaison between the user community and the OSAF board.

• Keep the board up to date on community activities and vice versa.
• Advocate on behalf of the user community at board meetings (e.g. if board is making strategic decisions about pursuing partnerships or allocating funds for projects.)
• Generally act as a 2-way communication channel between users and the board.