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.

[benoitc]

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.

I understand that. But the doc must exist somewhere. Since this report is a meta repo for all infra,saying where to find the documentation of the website is also useful. also understanding how work publication is useful to link this part of the website from other parts.

[ahw59]

where to get the stats

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

I'm not sure that is true. Fastmail has a JMAP interface / API that they were pitching at the IETF. In fact it now got accepted at the IETF (see the second link) https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/ https://jmap.io/

[starbelly]

I understand that. But the doc must exist somewhere. Since this report is a meta repo for all infra,saying where to find the documentation of the website is also useful. also understanding how work publication is useful to link this part of the website from other parts.

Linking makes sense.

[starbelly]

where to get the stats

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

I'm not sure that is true. Fastmail has a JMAP interface / API that they were pitching at the IETF. In fact it now got accepted at the IETF (see the second link) https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/ https://jmap.io/

I'm not sure I follow. I mean, I follow jmap and have read a few articles on it, but I think what @benoitc was referring to was an interface in fastmail that would give us statistics on our account/domain overall (e.g., incoming rejection rate for the domain, outgoing deferral rate for the domain, etc.). For comparrison gmail offers (or offered) such a tool called gmail meter. Unless I misunderstood @benoitc.

[starbelly]

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

I think I ask myself "Why is this useful? Why are we so concerned with making it public?". That said, I don't have a huge problem with making it public but as far as I know no one has reviewed the contents of the repository sans myself, this has to be done first by someone who is not bias. @benoitc

[benoitc]

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

I think I ask myself "Why is this useful? Why are we so concerned with making it public?". That said, I don't have a huge problem with making it public but as far as I know no one has reviewed the contents of the repository sans myself, this has to be done first by someone who is not bias. @benoitc

Having our doc public helps anyone to figure how we work and can trigger some help. Also beeing open is a good way to share and exchange our method/tools with others. Lot of orgs I know are doing it for such purpose. There are many others benefit also like ensuring we are following our own values. Open companies like buffer or in some extent Gorman with their handbooks are good example about it.

[benoitc]

I think documentation is an important part of making sure anyone can help us. Just tagging issues won't help if we have no documentation available. Also we should make sure to be able to update the website whatever happen to people. I will create a documentation folde herer and start to create a structure.

[benoitc]

where to get the stats

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

I'm not sure that is true. Fastmail has a JMAP interface / API that they were pitching at the IETF. In fact it now got accepted at the IETF (see the second link) https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/ https://jmap.io/

I'm not sure I follow. I mean, I follow jmap and have read a few articles on it, but I think what @benoitc was referring to was an interface in fastmail that would give us statistics on our account/domain overall (e.g., incoming rejection rate for the domain, outgoing deferral rate for the domain, etc.). For comparrison gmail offers (or offered) such a tool called gmail meter. Unless I misunderstood @benoitc.

we can probably build some metrics from fastmail. But i was more thinking on having the number of users created/deleted/updated/storage size. Elements to watch so we can keep and anticipate the budget for it

[starbelly]

I definitely agree with that. Since fastmail doesn't seem to have a UI, not like what you want though for this and we have problems with logging in as an admin, what do you suggest?

Let me note that you can login to fastmail, go to the billing details and get some of the numbers you're after. Namely the total number of users we are paying for and a break down of the split of users on a per plan basis. I would say login and take a look at that and find what's missing in regards to what you're suggesting. Maybe what's there is good enough.

Finally, let me note again (because over-communication is good) : I did try logging into fastmail programmatically as an admin, but after not making any progress after 2 hours, I cut my losses and said I will come back to this when there's time. It may be all I needed was a second pair of eyes and there was something simple I was overlooking. Happy to further that part of the discussion in private.

[benoitc]

To relay the work started by @starbelly (thanks!) , doc have been started on https://github.com/erlef/infra-wg/wiki

Do we receive notifications on wiki updates? I didn’t get any myself

[starbelly]

Do we receive notifications on wiki updates? I didn’t get any myself

I don't believe we do, no. And a comment to add is it's a start, but it's only a start, there are some particular places that indeed could benefit from screenshots, we'll get there. At the moment, I must turn my attention to other matters in the back log, but will carve out more time for this later in the week.