[impdev] Communications policy

Adric R hakushakukun at gmail.com
Tue Mar 15 23:20:20 PDT 2011


On Tue, Mar 15, 2011 at 4:33 PM, Jacek Antonelli <jacek at kokuaviewer.org>wrote:

> At our meetup last week, we discussed making some changes to our
> project communication channels (forums, issue tracker, mailing list,
> etc.), to make things more organized and easier to follow. We decided
> that a good first step is to define a policy about how each channel
> should be used, and to make that policy clear to our users. I'm
> working on that policy, but I have a few things I would like to get
> some feedback on:
>
>  * What should users do with crash logs? I'm assuming that we'll set
> up a proper crash report collection system eventually, but people need
> to know what to do in the meantime. Should they file an issue, or
> email us, or what? I'd say that reproducable crashes should be
> reported on the issue tracker, but what about random/unknown cause
> crashes?
>

Setting up the crash reporter--at least for Windows--is mostly a matter of
collecting them somewhere. It'd help immensely to have this available, as
it's very hard to debug crashes without crash dumps on Win (most people will
attach their log rather than Imprudence.dmp). I'd rather tell people to
attach them to redmine in the meantime, even if they can't reproduce it. If
nothing else it could give us clues on problem areas.

>
>  * How should users provide feedback about a release (stable or
> experimental)? In the past we created a forum thread for each release,
> but I think that should change. I'd say that bugs should be reported
> on the issue tracker as usual, but other feedback (questions, general
> complaints, praise, etc.) should be posted as a comment on the blog
> post announcing the release. Does that sound alright, or can you think
> of a better way?
>

Every bug should be reported on the issue tracker. Let's keep it
consolidated. Mandatory fields should be at least version (maybe we could
have two pull downs--one for month and the other for day--for reporting for
the experimentals?) and Help > About Imprudence. I added a button to the
About window that copies people's system info to their clipboards, so it
should be easier for them to provide that info to us now. Personally, I like
having the issue tracker be the only place we look for bugs. Sifting through
the forums takes up too much of my time.

What I *don't* want to do is have our issue tracker turn into, say, LL's,
where issues are closed because they don't have enough info in them or
because they aren't read fully or just because they've been open for a long
time. I'd rather have a "messy" issue tracker than an unfriendly one.

I like the blog for providing feedback on releases since people don't have
to register, but I don't have any opinion other than that.



>  * What should users do if they experience a problem and aren't sure
> whether it is a bug with the viewer, something wrong with their
> system, or user error? I was thinking perhaps they should:
>
>    1. First, check the knowledgebase/Q&A (when we get it set up).
>    2. If the knowledgebase doesn't have a solution, get help from
> other users/our support team by posting in a "Tech Support" forum
> section or using the inworld group chat.
>    3. If it turns out to be a bug in the viewer, check the issue
> tracker for an existing bug report, and file a new bug report if there
> is none yet.


>  What are your thoughts on this?
>

My thought's still the same as at the meeting: send users to one webpage,
then let them pick from that page what option suits their needs best, and go
from there. Here're some use cases:

Frank crashed in Imprudence. He wants to help us fix the crash, but he
doesn't know what to do, so he goes to the website and sees a link for "Info
and Support" and under it some helpful text, such as "Have a question? Want
to provide feedback? Need help?" Frank clicks the link, which takes him to
our support page. On the page, he sees several categories in large bold
letters, each signifying part of the site. For example:

* Ask a question (knowledge base)
* Report a bug (redmine)
* Talk to other users (forums)
* Documentation (wiki)

He wants to report a bug, but he's not sure how. He clicks on "Report a bug"
anyway, and thankfully he's taken to a page with images which shows him how
a proper bug report should look. He registers on redmine and posts what he
knows.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Anne doesn't know if Imprudence has breast physics and wants to find out
before she downloads it. She goes to the site looking for a list of features
but really doesn't want to scroll through release notes to find the answer
to her question. Impatient, she clicks the "have a question?" link and is
taken to the support page, where she then clicks "Ask a question". The
knowledge base (which codie setup) is good at taking feedback in the form of
questions and spitting out answers. She types in "Does Imprudence have
breast physics?" and the top link is a knowledge base article about the
feature, which shows how to toggle it, change settings, etc. Satisfied, she
downloads Imprudence.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Jerry is a developer interested in compiling viewers and submitting patches
to improve them. He doesn't need fancy-shmancy support pages (that's what
"man" is for) but he does need to know how to compile the viewer and submit
code. He immediately goes to "Documentation," which has takes him to the
main wiki page, which is full of his kind of geek lingo. He clicks the "how
to compile" link and in short order has a working build environment setup.
If he wanted, he could've put "compiling" into the knowledge base search and
gotten to the same info, but Jerry has a deep mistrust of support pages.

Hope that makes sense.

-- MC



> - Jacek
> _______________________________________________
> ImpDev mailing list
> ImpDev at lists.imprudenceviewer.org
> http://lists.imprudenceviewer.org/listinfo.cgi/impdev-imprudenceviewer.org
>



-- 
"Work is love made visible." — Kahlil Gibran

"We will not walk in fear, one of another. We will not be driven by fear
into an age of unreason if we dig deep in our history and doctrine and
remember that we are not descended from fearful men, not from men who feared
to write, to speak, to associate and to defend causes which were for the
moment unpopular. We can deny our heritage and our history, but we cannot
escape responsibility for the result. There is no way for a citizen of the
Republic to abdicate his responsibility." -- Edward R. Murrow, March 9, 1954
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.imprudenceviewer.org/pipermail/impdev-imprudenceviewer.org/attachments/20110315/941f0aa5/attachment-0001.htm>


More information about the ImpDev mailing list