comments below
"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.
>>>> I would still suggest
this is the same type of person but we just need to make it easy to download
stuff. In fact I think we need this for all types of audiences.
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?
>>>> I guess I misunderstood
what membership info meant. I thought it was about how to be a member. I
would suggest what you are describing is not actually membership info, it is a
description of who is contributing to each project. I agree, something
very important to communicate. I actually think the TPTP project is doing
a good job in this area.
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?
>>> There are probably two types
of grouping. Function/technology grouping and how the person
identifies themselves. I believe it is more important to group
based on how people identify themselves.
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?
>>>>> I agree but then they
are acting as a contributor not a plug-in developer. Users will
also report bugs. I think the important point is that one
individual will act as all the different types of audience. We need to
make sure it is dead easy to switch.
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
>>>>>> Do you mean a
project at Eclipse or another open source community. Recruiting
help for an Eclipse project would be a function of a committer or PMC? No?
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?
>>> I would suggest we take a
look at what TPTP is doing. On their home page they list the
companies contributing and all also profiling each committer. Not
sure if we want to do this for all projects but it should at least be an
option.
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?
>>> I really don’t
know L This is probably something we won’t do in the
first round.
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?
>>> I agree
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