Problem: Even if volunteers wanted to help, they wouldn't know how to do it. Nobody even knows what they don't know in specific enough terms to go get the information.
Other Problem: People in fundraising (not-tech) don't know how the heck things work in the system, and they have no resource but to ask one of us.
Bigger Problem: People in fundraising TECH don't even know how things were intended to work half the time.

Publicly Documenting the Donation Pipeline

What We Have Now

A ton of documentation on collab and in google docs, which

Are intended for the wrong audience (people who already know things about stuff)
Contain specks of private information we shouldn't move to a public wiki

What We Need

A nice solid overview for every major moving part. This should be expected to be significantly more granular than just breaking it out by codebase. Codebase may make sense to developers, but individual products are going to make sense for non-tech people.

Diagram. Even if it's just a whiteboard drawing.
How it currently works
How it's intended to work
What's upstream / downstream
Controlling system / codebase
Links to related bugs / cards in mingle or wherever

Maybe we can do something insane with templates to surface some of those lines in a relatively unobtrusive way... As in, the information would be there if you want it, but it doesn't jump out from behind the shrubberies and confuse people who basically don't care.

I think everybody else just documents by mediawiki extension, but we're going to have to get a little more creative than that. Particularly because we are assuming that this documentation is also going to be for non-technical people.

What Now

Quim says we should put it all on mediawiki.org, even though it's a little strange because very little of it actually has anything to do with the mediawiki codebase. Searchability is nice, and we're not really that much of an edgecase here.
Go through the specific things that we have internally (collab, office), that should be replicated externally.
Get totally bogged down in looking through what we have now and NO, YOU ARE DOING IT WRONG. Lighter overview for now or you will just get stuck.
- Office Wiki Fundraising Engineering category - This should probably all live somewhere else.
- Meanwhile on Office wiki, there are a bunch of old cute pages like this one that don't seem to be categorized, and are only good for the historical perspective... but still probably outside the scope of this first project.
- Collab is the actual jungle. First, there's the Fundraising Engineering Category. There is a whole lot more in just fundraising that I don't really want to cope with as part of this (which also makes sense).
- Fundraising Engineering on Meta is probably deceptively under-populated.
- Fundraising category on Wikitech. Sort of reasonable, probably because it's public. Maybe I can start by removing all complete lies.
- Fundraising category on mediawiki. I'm really not sure how we're supposed to divide this up, other than if it's a mediawiki extension it should probably go here. Or, I suppose if it gets people closer to the repos.
Talk to pizzzacat about general approach we want to take
Do that creepy thing where I just sit there and write / draw everything that spews straight out of my head.
See if any of what comes out can be templated in a reasonable way, sort of like what I was trying to do on collab.
- Note to self: Dude, you should finish what you were trying to do on collab. That was actually going to eventually become sort of neat.
- But maybe when we do it wherever we do it for the public, we just list dependencies and connected pieces as "related to" instead of trying to inject the upstream/downstream directionality mess.
- The weird part is going to be trying to click through this thing by gateway (think Donor Services - related reasons to look stuff like this up)... but I can have some degree of slickness there too, I think. For instance, in DoantionInterface we can document general ways that things work and add categories for the gateways / methods that work that way.