Change "In Progress" state to "Draft".

Payment requests are basically always "in progress" until they're
rejected or the requestor receives payment. Use a name that better
reflects what's going on.

Policy validation can wait until after the first release.

The policy validations that would help reduce back and forth most are
the ones that are hard to implement: checking that attachments
actually include the necessary information, checking that per diems
match limits, etc. Building to be able to accommodate these is going
to take time, and we don't need to make all that investment for the
first release.

Pre-approval can wait until after the first release.

This is a very valuable feature, and we want it soon, but it doesn't
have to be in literally the first release.

They aren't possible, but maybe are necessary.

I agree that all the items listed in here aren't possible given the time
allotted for development, and I haven't tried to integrate any of them
into the main feature set to avoid feature creep. However, some of them
are going to be necessary, and early users may need to realize that some
out-of-band workarounds will be necessary in the first version, because
the features listed here were, well, necessary. :)

Ensure user freedom for Javascript.

The fundamental point here probably goes without saying given who the
project leader is. ;)

The LibreJS thing may end up to be nice-to-have. LibreJS has some
serious problems -- I've had difficulty getting websites to work with
the plugin because the LibreJS plugin makes overly simplistic
assumptions about how Javascript is often deployed on a website.

But, we should try to be compatible if it's possible.

Knuth says it, I believe it, that settles it.

https://cs.stanford.edu/~uno/email.html

Wordsmith,grammar, and formatting changes.

No substantive change here, just writing style, grammar, and formatting
changes.

Additional wishlist for currency stuff.

The currency stuff is going to be complicated, but I agree completely we
should leave it wishlist'ed.

Plural pronouns for singular annoys me.

I really believe in gender fairness and fluidness in prounouning, and I
get why "they" is always better to use, and that the "one's request"
construction is too tortured. So, I tend to just write everything in
plurals if possible which keeps 'they' but makes the number
grammatically agree.

Yes, I know that the ADT made "they/them used as singular" as 2015 word
of the year. (see
https://en.wikipedia.org/wiki/Word_of_the_year#American_Dialect_Society

so maybe some nun slapped the table too hard with her ruler when made
some plural/singular mistake with a pronoun when I was in grade school,
but I have a compulsive need to change everything to plural when I see
"they" and am editing a document. ;)

Additional request state: Pre-Approval

Many travel policies, for example, require that certain expenses be
approved before tickets can be purchased. An example from Conservancy's
travel policy include: hotel bookings beyond the GSA/Dept-of-State Per
Diem hotel rate, and flights that exceed the with-$100-of-cheapest rule.

As such, requestors need the ability to request preapproval.

These changes herein committed, however, do *not* account for the fact
that a request may already be "In Progress" when another expense comes
up. An example of that is a flight was booked already in policy and the
requestor, and uploaded, and the requestor then discovers later that the
hotel is out-of-policy and needs preapproval. We can perhaps ignore
this scenario for the first specification of this to avoid
feature-creep, but I wanted to flag it as a potential issue for future.

The work around might be that the Bookkeeper is allowed to move a
request between any state to another, so the work-around in this
specific instance may have to require an out-of-band conversation
between bookkeeper and requestor. That's not disaster.

member => requestor

The requestor for payment may or may not be a member or affiliated in
some way with the organization.

Slightly increase scope: include payment requests

The project should really include outgoing payments along with it.
Submitting an invoice for payment as an external party is really just a
"base case" of a reimbursement request.

The only complication I can imagine this adds is allowing the general
public to create an account on the system, or allow for anonymous
submission, which might lead to spam concerns in deployment.

I believe these issues should be easily mitigated and will not
drastically increase scope of the project.

As part of this actual change to the text, some wordsmithing and changes
throughout to s/reimbursement/outgoing payments/ and other similar
changes are made.

Policy validation can wait until after the first release.

The policy validations that would help reduce back and forth most are
the ones that are hard to implement: checking that attachments
actually include the necessary information, checking that per diems
match limits, etc. Building to be able to accommodate these is going
to take time, and we don't need to make all that investment for the
first release.

Pre-approval can wait until after the first release.

This is a very valuable feature, and we want it soon, but it doesn't
have to be in literally the first release.

They aren't possible, but maybe are necessary.

I agree that all the items listed in here aren't possible given the time
allotted for development, and I haven't tried to integrate any of them
into the main feature set to avoid feature creep. However, some of them
are going to be necessary, and early users may need to realize that some
out-of-band workarounds will be necessary in the first version, because
the features listed here were, well, necessary. :)

Ensure user freedom for Javascript.

The fundamental point here probably goes without saying given who the
project leader is. ;)

The LibreJS thing may end up to be nice-to-have. LibreJS has some
serious problems -- I've had difficulty getting websites to work with
the plugin because the LibreJS plugin makes overly simplistic
assumptions about how Javascript is often deployed on a website.

But, we should try to be compatible if it's possible.

Knuth says it, I believe it, that settles it.

https://cs.stanford.edu/~uno/email.html

Wordsmith,grammar, and formatting changes.

No substantive change here, just writing style, grammar, and formatting
changes.

Additional wishlist for currency stuff.

The currency stuff is going to be complicated, but I agree completely we
should leave it wishlist'ed.

Plural pronouns for singular annoys me.

I really believe in gender fairness and fluidness in prounouning, and I
get why "they" is always better to use, and that the "one's request"
construction is too tortured. So, I tend to just write everything in
plurals if possible which keeps 'they' but makes the number
grammatically agree.

Yes, I know that the ADT made "they/them used as singular" as 2015 word
of the year. (see
https://en.wikipedia.org/wiki/Word_of_the_year#American_Dialect_Society

so maybe some nun slapped the table too hard with her ruler when made
some plural/singular mistake with a pronoun when I was in grade school,
but I have a compulsive need to change everything to plural when I see
"they" and am editing a document. ;)

Additional request state: Pre-Approval

Many travel policies, for example, require that certain expenses be
approved before tickets can be purchased. An example from Conservancy's
travel policy include: hotel bookings beyond the GSA/Dept-of-State Per
Diem hotel rate, and flights that exceed the with-$100-of-cheapest rule.

As such, requestors need the ability to request preapproval.

These changes herein committed, however, do *not* account for the fact
that a request may already be "In Progress" when another expense comes
up. An example of that is a flight was booked already in policy and the
requestor, and uploaded, and the requestor then discovers later that the
hotel is out-of-policy and needs preapproval. We can perhaps ignore
this scenario for the first specification of this to avoid
feature-creep, but I wanted to flag it as a potential issue for future.

The work around might be that the Bookkeeper is allowed to move a
request between any state to another, so the work-around in this
specific instance may have to require an out-of-band conversation
between bookkeeper and requestor. That's not disaster.

member => requestor

The requestor for payment may or may not be a member or affiliated in
some way with the organization.

Slightly increase scope: include payment requests

The project should really include outgoing payments along with it.
Submitting an invoice for payment as an external party is really just a
"base case" of a reimbursement request.

The only complication I can imagine this adds is allowing the general
public to create an account on the system, or allow for anonymous
submission, which might lead to spam concerns in deployment.

I believe these issues should be easily mitigated and will not
drastically increase scope of the project.

As part of this actual change to the text, some wordsmithing and changes
throughout to s/reimbursement/outgoing payments/ and other similar
changes are made.

Refresh the front page.

Remove outdated information, and update other tone of voice to better
reflect the current state of the project.

Formatting changes for better LibreJS parsing.

jxself suggested these changes would make things better for LibreJS.

Javascript details for LibreJS compliance.

I followed the instructions on
http://www.gnu.org/software/librejs/free-your-javascript.html to do
this.

Make it clearer that they should pick one of the projects.
HT lizhidong