phorge-phorge/src/docs/user/feedback.diviner

@title Give Feedback! Get Support!
@short Feedback/Support
@group intro

How to give us feedback, report bugs, and request features, and get support for
problems with Phabricator.

= Overview =

We'd love to hear your feedback about Phabricator, whether it's good or bad. We
stay on top of bug reports and fix many of them within a day or two (and
sometimes within hours). The Phabricator roadmap is determined in large part by
user feedback and feature requests. Your feedback matters, will often have an
immediate short-term impact, and the project leads are actively listening to it.

We also try to provide a very high level of free support. If you have trouble
with anything or just don't understand how something works, ask us! We're happy
to help, and it's usually valuable for us because we can prevent the problem
in the code (or document it better) so future users don't hit it.

Some day we will no doubt grow callous and distant, but for now the community
is small enough that we can provide a high level of service and support to
everyone and still have plenty of time to write code.

If you're in the SF bay area, we're also happy to come onsite and help you set
things up, answer any questions you might have, or just hang out and tell
Facebook war stories.

The best ways to provide feedback are:

= Maniphest =

The best way to report bugs and request features is through
[[http://secure.phabricator.com/maniphest/task/create/ | Maniphest]]. Just file
the bug/request and we'll handle everything else. (If it's time-sensitive or
blocking you, feel free to assign it to `epriestley`.) Feel free to file support
requests, general questions, or random feedback this way, too.

= GitHub Issues =

You can also use
[[https://github.com/facebook/phabricator/issues/new | GitHub Issues]] if you
prefer.

= IRC =

We're active in #phabricator on FreeNode, and it's the best place to ask
questions and get support.

= Email =

You can email us at `btrahan@phacility.com` and `epriestley@phacility.com`.

= Filing Good Feature Requests =

When filing a feature request, please provide as much information as possible,
especially about what your use case is and why you want the feature. Explaining
what your larger goals are is very helpful, and lets us design better features.
Tell us what your problem is before you tell us your idea to solve it: sometimes
we can come up with a better approach to the problem, a slightly different
approach that solves more problems or helps other users, or a way to make the
problem go away entirely.

= Filing Good Bug Reports =

When filing a bug report, please provide as much information as possible. In
particular:

  - If you received an error message, please please please provide it! It is
    often incredibly useful. See @{article:Please Please Please}.
  - The second most useful thing to us is reproduction steps. If at all
    possible, provide a brief list of steps required to reproduce the problem.
  - If something you didn't expect (other than a crash or obvious error)
    happened, tell us what you expected and what actually happened.

We can fix clearly-described bugs with reproduction steps and error messages
much more quickly than vague bugs we can't reproduce.

In particular, if you don't include error messages, we need to ask you for error
messages. We will nearly always need to do this, and nearly always be unable
to continue until you provide them. You'll save everyone time if you spend a
few extra seconds copy/pasting them in the first place.

Generally, err on the side of giving us too much information. It's much quicker
and easier for us to filter out information that isn't relevant than it is to
go back and forth asking you to provide more details.

Tips:

  - For issues with `arc`, you can get more information by running the command
    with the `--trace` flag. For instance, run `arc diff --trace` instead of
    `arc diff`. Including this output in your bug report is often helpful.
  - For issues with Phabricator, check your webserver error logs for more
    information. For Apache, this is usually `/var/log/httpd/error.log` or
    `/var/log/apache2/error.log`.
  - For issues with the UI, check your Javascript error console in your browser.
  - Some other things, like daemons, have debug flags or troubleshooting steps
    covered in their documentation. Enabling these flags may give you more
    information about the problem.

= Unreproducible Problems =

Before we can fix a bug, we need to reproduce it. If we can't reproduce a
problem, we can't tell if we've fixed it and often won't be able to figure out
why it is occurring.

Most problems reproduce easily, but some are more difficult to reproduce. We
will generally make a reasonable effort to reproduce problems, but sometimes
we will be unable to reproduce an issue.

Many of these unreproducible issues turn out to be bizarre environmental
problems that are unique to one user's install, and figuring out what is wrong
takes a very long time with a lot of back and forth as we ask questions to
narrow down the cause of the problem. When we eventually figure it out and fix
it, few others benefit (in some cases, no one else). This sort of fishing
expedition is not a good use of anyone's time, and it's very hard for us to
prioritize solving these problems because they represent a huge effort for very
little benefit. These problems are a tiny fraction of requests (maybe 1-2%) but
take up the vast majority of our support effort (maybe 80%).

**If you want us to fix a bug we can't reproduce, you need to build us a working
reproduction case.** Generally, this means a `root` login on a machine where the
issue occurs. For example:

  - Bring up a new machine (e.g., in EC2), install Phabricator on it, configure
    it so the problem is reproducible, and then give us access to it.
  - If the machine Phabricator is running on is nonessential/nonsensitive and
    you're comfortable with us having root on it, give us credentials.
  - If the issue is with Git, SVN or Mercurial, create a new empty repository,
    add a commit or series of commits which replicate the issue, and give us
    a zip/tarball of the repository as a reproduction case.
  - If you're in the San Francisco bay area, we can probably swing by and fix
    the issue onsite.

These are all fairly heavyweight and will take some time, but often //less//
of your time than a fishing expedition. If you can build a reproduction case,
there is a very high chance we can resolve your problem quickly.

Alternatively, you can pay us an enormous pile of money for some kind of
enterprise support thing and we'd be thrilled to go fishing with you for as long
as you remain solvent. Email us (see above) for specifics.

= Next Steps =

Continue by:

  - Filing a bug of feature request in
    [[http://secure.phabricator.com/maniphest/task/create/ | Maniphest]]; or
  - contributing to Phabricator with @{article:Contributor Introduction}.