Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [phoenix-dev] Audience Persona Sheet


Hi Ian!
This is good stuff - I'll take a pass at the Persona sheet to try to incorporate your notes.  Other notes below - see ** -
susan



"Ian Skerrett" <ianskerrett@xxxxxxxxxxx>
Sent by: phoenix-dev-bounces@xxxxxxxxxxx

03/29/2005 04:39 AM

Please respond to
For developers on the <phoenix-dev@xxxxxxxxxxx>

To
<phoenix-dev@xxxxxxxxxxx>
cc
Subject
RE: [phoenix-dev] Audience Persona Sheet





 
 
 Andrew,
 
 I think it is great that we are starting to identify the needs for each user.  This seems like a great start.  Here are some comments.
 
1. I really don’t understand the difference between consumer and user?  Just saying a user actually uses support resources seems to be pretty specific.    I would suggest that we have no idea if someone will actually use support resources.    In fact, we should always strive for making sure Consumers are aware and take advantage of the support resources.  That way we can help ensure they are successful.  In my mind these seem to be the same category.
**The consumer is meant to mean the guy who just wants to download something 'now', without futzing around in project info.  A consumer can become a user when they start needing more than just a quick, clear way to the downloads.

2. Why does a user care about membership information? We actually don’t offer membership to users.
**If they're new, or evaluating, they might use the 'pedigree' from the members to contribute to a decision.  They might also use a member's plugin if the info were there?

3. Users are interested in communicating with other users to share experiences or learn from other people.   We need to create an environment to make this happen.   Things like ranking systems for white papers, documentation, even Eclipe projects.
4. I believe we will have different types of users.  Off the top of my head we have Java developers, J2EE develoeprs, embedded developers, C/C++ developers, Linux developers, architects, testers.  We need to present information that is relevant to what they are trying to do.
**I'd add that we also have folks who are looking for RCP, API, debugger specific info.  Maybe we could group these under something called 'Themes" that would cut across the project organization?

5. Is the neeed ‘How to start a project’ meant to be ‘How to start an Eclipse open source project?’   or How to use the Eclipse IDE and use the project wizard.  I think you mean the ‘start an open source project’?  If so, then I think the majority of users will not care about this.  If fact I think very few people care about how to start an open source project.  
6.  Users will want to know other resources for support.  Where can they get help and information that might not be on eclipse.org.  For instance, what seminars/trade shows are available.
7. For Plug-in developers, I don’t see them posting release plans or architecture documents on eclipse.org.   Plug-in developers have no formal relationship with eclipse.org and are focus on creating ‘products’.either for commerical sale or open source distribution.  
**they may be contributors - if they find bugs, provide fixes in the process of creating their plugins?

8. Plug-in developers will be interested in promoting their ‘product’ on eclipse.org.
**they may also be interested in recruiting help for a project

9. Member companies are interested in promoting their products via eclipse.org.  I think we can do this via a product catalog, membership listing, and highlighting their news items.  We will also provide ‘members only’ marketing opportunities for participating in trade shows, advertising, editorial content, market research, etc.
10. Member companies also want to get credit for being associated with Eclipse and providing resources to eclipse.
**What are some ways we can give credit?

11. A benefit of being a member is the ability to network with other member companies.   We can do this via f2f meeting but it would also be interesting to find options to do it via the internet.
**What sort of electronic networking do you think they'd participate in?

12. Member companies would like to have insight into the user community, ie stats on usage of projects.
**This goes beyond 'click stream' data and maybe relates to 11 in that if we are connecting users to the members through our website, its a form of networking.  Shouldn't there be an input point as well when projects are developing their feature and release plans?
 


Susan



From: phoenix-dev-admin@xxxxxxxxxxx [mailto:phoenix-dev-admin@xxxxxxxxxxx] On Behalf Of andrew geraghty
Sent:
March 24, 2005 4:46 PM
To:
'Susan Iwai'
Cc:
phoenix-dev@xxxxxxxxxxx
Subject:
[phoenix-dev] Audience Persona Sheet

 
Susan,
I have compiled emails/discussions info this chart.
Obviously we are currently working from the general and slowly getting more specific and detailed. In tandem with this exercise, and the benchmark site analysis, we need a content audit so we can document the volume and complexity of the current state of the content and functionality on Eclipse.org
The three documents combined will be useful for the core team to form preliminary design and functional targets (optimisation and efficiency recommendations)
 
Comments Welcome
Andrew
 
Audience Member Title Description Identified Needs
Consumer • anyone who downloads Eclipse tools but does not use Eclipse support resources • want to use Eclipse (download specific Eclipse tool, specific information)
• articles, white papers, technology introductions
User • person who makes use of one or more Eclipse projects (tools) to perform some function including support resources • how to start a project (write programs)
• about the foundation
• membership information
• Ask for help / read about their tools
• Learn about (via push technology) updates to their tools
•  Learn about (via push and pull) the future release plans for the tools they are interested in
•  Learn about places they can purchase solutions to problems that Eclipse.org does not offer

 
Committer • Contributor who works on one or more Eclipse projects with the ability to write to Eclipse's CVS repositories • Self management of their content within the context of a general framework
•  how to start a project

•  Find out about (and post) release plans
•  Find out about (and post) architecture documents
•  Find out about cross project information of interest, such as release and architectural and API changes, probably via a push technology
•  Read and post blogs, wikis, and other iteratative information schemes to generate a collaborative discussion and documentation about the project and its code
•  In general, increase the utility and validity of each bit of information posted

•  Filter out "please help me" user requests
Contributor anyone who provides content on the Eclipse website including those who:
• make a single news posting
• who work full-time contributing code to one or more Eclipse (but who for whatever reason are not a committer)
•  sends an email to a mailing list,
•  files a bug using Bugzilla
• Self management of their content within the context of a general framework
•  how to start a project

•  Find out about (and post) release plans
•  Find out about (and post) architecture documents
•  Find out about cross project information of interest, such as release and architectural and API changes, probably via a push technology
•  Read and post blogs, wikis, and other iteratative information schemes to generate a collaborative discussion and documentation about the project and its code
•  In general, increase the utility and validity of each bit of information posted

•  Filter out "please help me" user requests
 
Plug-In Developer • has an interest in building and/or deploying one or more Eclipse plug-ins with the purpose of extending the capabilities of the Eclipse Platform • how to start a project
• Self management of their content within the context of a general framework
•  how to start a project

•  Find out about (and post) release plans
•  Find out about (and post) architecture documents
•  Find out about cross project information of interest, such as release and architectural and API changes, probably via a push technology
•  Read and post blogs, wikis, and other iteratative information schemes to generate a collaborative discussion and documentation about the project and its code
•  In general, increase the utility and validity of each bit of information posted

•  Filter out "please help me" user requests
 
Corporate Member • Companies that support Eclipse and have joined the Foundation as an add-in provider and/or associate member • provide company profile surrounding my membership
Member • Committer who has joined the foundation as a voting member of the committer member class

 _______________________________________________
phoenix-dev mailing list
phoenix-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/phoenix-dev


Back to the top