Recent changes to this wiki:

Reimbursements: Add note about CiviCRM's Money type.
index: Update Call to Action.
* Simple sentences with present tone.
* Reorganize a bit for current priorities.
index: Link to Reimbursements project index.
Reimbursements: Add index page dedicated to the project.
Reimbursements: Update CiviCRM upload security note.
Reimbursements: Start notes about a CiviCRM extension implementation.
test web editing on new server
Add payment automation as a desired reimbursements feature.
index: Fix link typo.
index: Refresh with current plans.
* Note work on the reimbursement system.
* Streamline ways to help.
* Remove Phase 1 plans for now, since they're less reflective of the
current approach. A lot of the materials are still relevant, but we
need to figure out a better presentation for them, and they're not
critical now.
Add Desired Features section with iCalendar export.
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.
Expand desired lifecycle tracking.
markup cleanup
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.
copyediting
Better explain the functionality line between first and later releases.
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.
demo list continuation
show subblock in list
demonstrate code block
demonstrate inline code
add code block
add another subitem
add sub-item
demonstrate bold
Americanize spelling
add more instructions
remove nonfunctioning calendar
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.
Refill paragraphs; no content changes.
First draft requirements for reimbursement system.
Refresh the front page.
Remove outdated information, and update other tone of voice to better
reflect the current state of the project.
List hledger with other ledger-alikes
Copy evaluation template in for hledger
Formatting changes for better LibreJS parsing.
jxself suggested these changes would make things better for LibreJS.
Fix location.
Another formatting fix.
Put info in a different place on page.
HTML formatting fixes.
Javascript details for LibreJS compliance.
I followed the instructions on
http://www.gnu.org/software/librejs/free-your-javascript.html to do
this.
Add application tips for this task.
Update numbers, note that two may get picked.
Note how this relates to (1).
Simplify
Link hledger-web
Link Hledger
Add some kind of hledger project option, as discussed
fix typo
Add note about the type of student we're looking for for this project.
Joining to the project.
Make it clearer that they should pick one of the projects.
HT lizhidong
Missing period.
Attempt to do a formating fix.
Add "submit patches" to "How To Help"; make clear link to "How To Help"
We now have four choices.
A few more items about this task.
Force <br />'s, perhaps that will look better?
Revert last change, that screwed up formatting!
See how separating the items with <hr/> looks.
Skip more lines between items.
Bullet list was indented too far. (Whitespace only changes here)
Add a GSoC idea: fixed-point arithmetic in Ledger-CLI.
Fix typo.
Improved description of test task based on johnw input.
Reword first item, more notes for potential students.
Grammar Fix.
A little more detail on this.
note that upstream is Ledger-CLI here.
More details on this, and note that upstream is Ledger-CLI here.
Note that the student may be able to use API to do some reports.
First draft of GSoC 2014 Student ideas.
Note GSoC and Phase 1 details.
Explain Phase 1.
Added 2014-01 work report
Reverted badsons commit c9f367
This reverts commit 7f7144ef484ed0b7736e7000ba264532bcfbe40b
Removed badson spam pages.
Added work report for 2013-12
This reverts commit 2d97b0f7a535dd24a3363cfffabcdff359611afd