document our assets

[benoitc]

As already discussed, we should ensure not not loose any information on what have been (and is ) done by @starbelly when he was under contract and other assets/tools managed by the WG that the foundation use.

I am creating here a temporary list before we go for a full backlog. I put in it what should be documented for the admins and other people that would like to help or join the group. There are probably some items missing, so feel free to complete it :)

* Credentials
 * where to get them
 * how to request them
 * administrative process

* Emails
  * who can admin them
  * how to setup/delete/edit an alias/account. Any useful links that ease the operations
  * where to get the stats
  

* Website
 * Requirements to develop on it
 * general overview  of its architecture
 * document data strucrures used and links between them
 * document the features inside the website:
   * stipends
   * reports
   * sponsoring
 * how to administrate it.
 * how to update the content/ Who can update it. 
 * where it is hosted
 * more generally what processes are in place to operate it (publishing, ...)
 * backup policy
 * where to collect stats


* Users
 * how the daabase of members of users can be accessed for the development, what have been done
 * how to access to wild apricot / processes actually in place to manage & contact them

* Slack
* How it isoperated
* What ois the process to request a room/ (create one if none)
* How invitations to it is working 

[benoitc]

also we should probably list how much time is required to operate each to see where we need help :)

[starbelly]

@benoitc I will carve out a day next week for this. As for some of the things in the list, specifically deployment, etc. it's already documented, we just need to link to it. In factt, most things in that list we will link to other docs. For example, we should not double up on slack's own documentation, nor 1password, etc. etc. We should instead link to their documentation.

As to how much time each thing takes up, we'd have to actually track that, I'm not sure that's terribly useful or what problem it solves.

[max-au]

Where exactly this documentation is located? (DNS setup is almost trivial now, but still has a few quirks worth documenting).

[starbelly]

@max-au So, we're going to put it all here, but documentation for say deployment etc in in erlef/infra-code, which is private. The start of another docs repo was infra-docs also private and not much there yet, I will move what's there into this repo and expand on it. I think we may link to infra-code vs putting docs in this wiki, as it's still not clear to me whether that should be public or private. In general I would add documentation to the wiki in this repo, I believe that's what we agreed upon : https://github.com/erlef/infra-wg/wiki

And yeah, you raise another point. I don't think documenting our dns provider makes sense, they already have docs for how to do everything. I think if we have any specific protocol for changing DNS etc, that's worth documenting, but I don't believe we have that, nor need it at this point. All IMO.

[starbelly]

I was going to carve out a day later this week for this, but I'm just going to nip this in the bud now.

[starbelly]

Note: Some of the things you mention documenting for the website should not be documented here. Application arch is specific to the application, not infrastructure.

how to administrate it.

Yes, belongs in this wiki

how to update the content/ Who can update it.

Does not belong in this wiki IMO. I mean, deployments yes, but limited to that. Like it doesn't make sense how to contribute to the website here, that belongs in the website repo.

[starbelly]

where to get the stats

Fastmail provides no statistical interfaces AFAIK. It is quite limited in this regard.

[starbelly]

I've added a few initial pages, we actually have to discuss some of the other stuff. Ranging from what belongs here to what really belongs in website documentation. Also, some of the things you are asking for here, it's policies, not operator documentation. That's different scope.

Some other ones I'm confused by :

• how the daabase of members of users can be accessed for the development, what have been done

I don't understand what this means. Generally, no one has access to do this. This is actually extremely problematic in regards to development. That is to say, it takes a rare bird who is able to make use of the WA API to develop a feature initially. Maybe thatt's what you're stating needs to be documented, but once again, we're drifting away from infrastructure, operative documentation and into policy. I can't define policies on a whim, they must be discussed and consensus must be reached and then we can document and put a policy into place.

• how to access to wild apricot / processes actually in place to manage & contact them

At best we can provide a link to wildapricot's documentation. But maybe I'm not understanding what you're suggesting here. I

I think we need to go over all this at the next meeting.

[starbelly]

Note to self: Add onboarding section for working groups and staff members

[benoitc]

@max-au So, we're going to put it all here, but documentation for say deployment etc in in erlef/infra-code, which is private. The start of another docs repo was infra-docs also private and not much there yet, I will move what's there into this repo and expand on it. I think we may link to infra-code vs putting docs in this wiki, as it's still not clear to me whether that should be public or private. In general I would add documentation to the wiki in this repo, I believe that's what we agreed upon : https://github.com/erlef/infra-wg/wiki

And yeah, you raise another point. I don't think documenting our dns provider makes sense, they already have docs for how to do everything. I think if we have any specific protocol for changing DNS etc, that's worth documenting, but I don't believe we have that, nor need it at this point. All IMO.

Why this doc has to be private? Until we don’t put in it a password, I don’t see a need to.

Every procedure, who to contact if any help is needed, where to find an information, must be documented. That the key to decentralize work. we may not have a formal protocol but documenting how things are actually done to update/change any part of the infra should be written. similar to a logbook somehow.