We should still use MarkDown processing, but remove EpicEditor from the article page.

The draft page is a little too confirming.

• "Your request has been created." makes it sound like you're all done.
• The green and check box reinforces that.
• The message should be more "almost there" and then make it easy to submit.
• I feel that having the button on the top right kind of makes it invisible if you're kind of scanning. If you're reviewing, you work your way down the screen and there's nothing to click. If you just want it filed, you want to click something in that "Almost there!" message up top. The current location feels very buried.

Not sure what's going on here, but looks like some absolute values are doing funky things and cutting off text on the request page that's there on the admin page?

http://muckrock-staging.herokuapp.com/foi/united-states-of-america-10/premium-travel-policies-nrc-10614/

Why are we indenting at all? Why aren't documents showing up in the main request view?

We should have a new task management system which is, to start, pretty much a simple model and a way for items to get into the model via Mailgun.

The model should include (all fields optional):

Title
Description
Date Created
Assigned to (Allow multiple users)
Priority (just a float number)
Project (Just a string, ideally allow multiple such as "Spylighter" and "Drone Census")
Completed (Boolean)
Due Date

This system will be, at first, purely in the backend. Admins should be able to get (and regenerated) keys (possibly same as API key?) to email into this system in the following format:

userstring+Spylighter+Drone_Census+due2d+priority30@tasks.muckrock.com

The subject line becomes the title, the body becomes the description. This would be assigned to Spylighter and marked due in two days. All fields are optional.

priority just checks for the word "Priority" and then assigns the value after that. due looks for m (month), d (day), w (week) , or y (year) and marks it due that many d/m/w/y after the task is received.

Everything should be accessible via API.

Instead of completed being a Boolean should be a should be status with options of:

• Open (default)
• Completed
• Declined

There are a lot of considerations (what about faxed or mailed requests, what about stupidly huge number of pages or size on attachment?), but eventually we should allow users to add attachments.

The statistics for the news stats currently does not work.

Some agencies (such as white house) should be in the database, but should not be FOIA-able. If a user tries to file with them, there should be a notification as to why, and brief tips on following up.

The "To Whom It May Concern:" and "Sincerely, User's Name" are missing from the requests being generated.

http://muckrock-staging.herokuapp.com/foi/memphis-319/drone-documents-memphis-12608/

On request pages, the button to edit tags and the request's status is visible even if I'm logged out.

Editing tags should be allowed only for the request creator and staff. Editing status should only be for staff.

To be done as part of overall task system:

I've been thinking a lot about the to mail issues the last few days, in
terms of the delays, tracking, one-click setting, etc.

I'd like to try breaking it out into a dedicated page (probably
/tasks/mail, and move orphans to /tasks/orphans) and have it skip
[email protected] entirely.

On that page it would just include every thing that currently needs to
be mailed, with links associated that go to:

— The request page.
— One click to send it out as mailed today.

• One click to send it out as mailed tomorrow (for things sent late in
  the day and postmarked the next day).
• Same as above, but to mark everything currently on the page as mailed
  out today/tomorrow.
• Notes if a payment needs to be included with a given mailer, including
  how much.
• A link to an HTML page that is exactly what needs to be printed and
  mailed for each communication, ready to just hit CTRL-P, so the
  processor can just open them all in tabs, print them all out, and mail
  them.
  — POSSIBLY a link to a one page-collation of the above that includes
  page breaks so you just have to hint print once, and can then use the
  one-click. I'm a bit wary of this, particularly at start, but thinking
  about it if it would work.

Eventually, we want to move communication handling out of the requests
inbox and into the site, to make it easier to crowdsource, to undo, and
to make sure stuff doesn't get lost, and I think this is a good first
step.

We can run this in parallel with the emails for a while as a
safety, but I'm concerned at how the emails for tomail stuff tend to get
pushed to late in the day or the next day, and I think this is a chance
to make the process as simple and as fool proof as possible, as well as
a good way of batching like tasks so that they're done more efficiently
and with fewer errors.

We should add the Google Analytics code for conversion tracking, ideally for both Pro and Community accounts separately, and possibly registration?

https://support.google.com/adwords/answer/1722021?ref_topic=3165803

No Responsive Documents updates should get a category all their own, above updated requests and below completed and requests needing action.

No Responsive Documents

Chief FOIA officer exemption 5 guidance (Internal Revenue Service)
Current status is No Responsive Documents
https://www.muckrock.com/foi/united-states-of-america-10/chief-foia-officer-exemption-5-guidance-internal-revenue-service-7088/

RSS feeds per request that include updates to the request.

Emails that are on the various MuckRock agency whitelists (.gov, an email that matches our database of agency emails, etc.) should be able to send to *@requests.muckrock.com and have the message go to orphans if it doesn't match an existing request email, even if it doesn't fit the pattern of ####-#######@requests.muckrock.com

Have some kind of regular, independent testing of our mailing domain to ensure we're not being spamblocked.

This is a longer term thing, just noted here to get it on the road map.

From Faxaway:

Hello;

Okay, the faxes failed, because there were so many messages addressed to the same fax number, at the same time, that all three fax attempts had a busy signal, because other faxes were being transmitted at the same time.

Please separate the emails (if they are to the same fax number) by 5 or so minutes, so that all the emails for the same fax number, are not received (or attempted to be processed) at the same time.

Thank you,

Kory Miller
[email protected]

Regarding this page:

https://www.dropbox.com/s/gv6ghwrcjlr8wrs/Screenshot%202014-05-07%2023.30.54.png

After amount, add new checkboxes:

Follow this request for updates on its status:
List my name as a contributor:
Both should be checked by default.

And then after the crowdfund summary it should list donors that submitted with the check mark checked like we do on this request:

https://www.muckrock.com/foi/united-states-of-america-10/fbi-drone-documents-1542/

Contributors

Scott Ainslie
Mark Erickson
Conor Skelding
... plus 1 anonymous supporter

More about this crowdfunding campaign. <- And then at a bottom, a link to the child news article, if applicable.

Users should be able to schedule one-time (on a certain date) and recurring requests (the request will be refiled weekly/monthly/yearly). It might be nice to include the ability to do some relative values ("I request any emails sent between [today's date - 1 week] to [today's date]") but for simplicity, just having recurring and scheduled requests would be very useful.

New Users in particular like to include their email address in requests, which is confusing to agencies and ends up breaking shit.

Once the new redesign is launched, we should include some kind of check to make sure users understand and don't put in their email address unless they really want to.

Ideally, it'll also check for addresses but that seems tricky.

The underline when hovering goes weirdly far in the menu on desktop.

I think this can be better. Instead of asking them to sign up, can we ask for:

• First Name
• Last Name
• Email

and then send them to the next page, with a small text link to let them log in if they have an account?

If a request is un-embargoed, those following it should get a notification. Less concerned about embargoing of requests because because the user who embargoed it already knows, and they probably aren't eager to advertise that fact to those following request.

We need to go back and unfeature all requests except the ones we feel are good cloning candidates.

Handle requests that branch and requests that are combined.

Allow users to pick from requests to clone on the filing page if they don't know what they're going after.

Rather than just appearing once at the end of the fix required's, the following tagline appears after each request

"See ALL request needing attention here:
https://www.muckrock.com/foi/mylist/action/"

It should just appear once.

3 RSS feeds on user pages that include:

• All a users new requests
• All updates to a user's requests
• All a user's completed requests.

We should offer a way for users to search through our documents on DocumentCloud. They offer a really nice API of their own, but I think it'd probably be better for us to pull the raw text data into our backend and allow searching through it on our main search interface.

If you start a request logged out, pick a jurisdiction and agency, and then log in, it keeps the agency information but loses the jurisdiction information. This then throws an error if you hit submit.

A few tweaks with crowdfunding:

On the "Enable Crowdfunding Page," it should offer a few more fields and explanatory text:
https://www.dropbox.com/s/99netyk85zkrl3c/Screenshot%202014-05-07%2023.10.56.png

Enable Crowdfunding for Request

Dog Registration Data (Saugus Town Clerk)

MuckRock makes it easy to crowdfund payments for requests when agencies ask for money. Explain (briefly) why you think release the information is important, interesting, or otherwise something people should support, and then optionally set how much additional money you'd like and how you would like to use it. Your crowdfunding campaign for the campaign will be begin immediately, while an editor will be in touch with you if you'd like to raise additional funding. Have more questions? Get in touch at [email protected].

and then fields:

Three sentences on why people should chip in:

Total amount you'd like to raise:
(automatically insert cost of request)

If you're asking for additional money, explain what you'd do with it here:

The crowdfunding campaign would then go live trying to raise either the request's costs OR "Total amount you'd like to raise," whichever is lower.

In ADDITION, a new article is saved as non-published with the current date and time and:

Title: Crowdfunding campaign for
Kicker: Help hit the $[total asked amount for campaign] goal

Summary: the three sentences

Body: The three sentences + afterwards.

Author: Whoever submitted the crowdfunding campaign request.

FOIAs: The FOIA the campaign is assigned to.

Also the crowdfund widget of any request tagged in the FOIAs of an article should should show up in article pages that tag that FOIA.

Crowdfund campaigns should also be able to have articles set as children to them, and if an article is the child of a crowdfund request that crowdfund request should pull the summary of it and run that summary under its "Crowdfund this request" header once the article's are approved by an editor and live.

We absolutely need a way for users to see what requests are newly update, which have fixes required, rejected, etc. in their request queue. Ideally this is some sort of live filtering, but at the very least we need a system that matches what we currently offer:

https://www.muckrock.com/foi/mylist/all/

Requests and articles should have share tools for Facebook, Twitter, plus easy-to-grab URLs to specific communications. I think we can skip the other social networks for now.

While I appreciate the retro charm, for our new hotness on the site we should have a new favicon to match. Fortunately, it looks what Allan whipped up for the mobile homepage should work nicely?

There should be some sort of fax verification mechanism that scans for incoming fax verification or failure emails, and adds a component that gracefully handles failed requests on site by allowing resubmissions or failures.

If you want to do a pattern, that might be ok but should be much more subtle. I'd skip a pattern and go with a solid color altogether to reduce load times however.

When uploaded, a fee waiver rejection letter currently changes the status to "Payment Required" -- this is typically not actually the case, as many requests remain free even if a fee waiver was declined. A number of users have been confused when their requests are changed to "Payment Required" but see no fee assessed. Furthermore, "Payment Required" stops automatic followups, so there is a risk of these requests drying up unnecessarily.

The status should not be changed to "Payment Required" unless the agency has indicated an amount to be paid.

Ideally, don't change the status at all.

We should study how things were between the From field experiments, and come up with a solution that works better for all situations.

Multi-requests should have preserve the "parent" multi-request and link back to it, so it's easy to see all requests filed as part of a multi-request and analysis can be done on resolutions to related requests.

Multi-requests should have tag support from when they are filed.

Can we add one-click approval for Bad Sender emails?

Suggested format:

Bad Sender: Receipt of FOIA Request FA-14-0050 (UNCLASSIFIED)

Target email address: [email protected]

Request Admin: http://www.muckrock.com/admin/foia/foiarequest/10944/

Accept email to request: http://j.mp/WHYVfv

Set status as Completed: https://www.muckrock.com/admin/foia/foiarequest/set_status/7706/done/735333/
Set status as Rejected: https://www.muckrock.com/admin/foia/foiarequest/set_status/7706/rejected/735333/
Set status as Partially Completed: https://www.muckrock.com/admin/foia/foiarequest/set_status/7706/partial/
Set status as No Responsive Documents: https://www.muckrock.com/admin/foia/foiarequest/set_status/7706/no_docs/735333/
Set status as Fix Required: https://www.muckrock.com/admin/foia/foiarequest/set_status/7706/fix/
Set status as Payment Required: https://www.muckrock.com/admin/foia/foiarequest/set_status/7706/payment/
Set status as Withdrawn: https://www.muckrock.com/admin/foia/foiarequest/set_status/7706/abandoned/735333/

The "accept" URL would:

1. Add the email to the request page as a FOIA communication, including all attachments.

2. Add the email address as the email for

Records officers are getting snippy about our blanket use of "Freedom of Information Request" in the subject line of emails and in followups.

Right now all of our requests, federal, state and local, have the following email line:

"Freedom of Information Request: (insert request name)"

And our followup language is as follows:

"I wanted to follow up on the following Freedom of Information request, copied below, and originally submitted on (date)."

This leads to responses like these: "Lastly, the federal freedom of information act applies to federal agencies of which neither the Miami Police nor the Miami-Dade Police Departments are, so you would be better making your request under Florida public records law instead"

Although our request body refers to the appropriate law, these details apparently matter to the people on the other end.

SO, I'd like our email subject lines to be customized to the jurisdiction:

For federal requests: "Freedom of Information Request: (insert request name)"
For state/local requests: "(State public records law) Request: (insert request name)"

And followup language will need to be customized not just for date of submission but also appropriate jurisdiction, as above.

The submit button doesn't seem to actually do anything.

We need to decide what we're promising, and what this will lead to. My instinct would be to a static page, so that we can easily update and tweak it over time. Maybe just muckrock.com/help? Allan, what did you have in mind?

A system to share both specific requests and a way to set a default sharing of requests.

Embedding that works better from both the tools side (getting the code) and links back to the request page.

It should be easy to see what request a cloned request came from, and follow back it's "lineage" crediting inspiration and helping users explore how FOIAs evolve.

This needs to be scoped more.

Can we change Invalid Address notifications to make it easier to track down and assign to the appropriate MR #??

Suggested format:

Email title: Invalid Address: Final Response to Request

Target email address: [email protected]

Add email to request: enter MR####

Remember to set the status appropriately before archiving!

The "accept" function would:

1. Add the email to the request page as a FOIA communication, including all attachments.

2. Add the email address as the email for the request.