These are good thoughts and you approached the problem methodically. You show draft examples and figures, which is good.

Detailed comments are below, more generally:

• The more detail you can provide (e.g., on what technology you think you'll be using or say that how to do X needs to be figured out – basically so that we see that you either already know how to do something or that you know what you need to learn)
• Propose a way to capture the background work that you are doing, for instance, we would like to maintain all the user profiles that you create. Also, having notes/templates for new docs would be terrific. Perhaps the easiest thing would be to create a repository under the MDAnalysis org for all the support material. Either way, proposing a way to keep the knowledge in the org would definitely strengthen the proposal.
• Have you been able to work with MDAnalysis (install, try tutorial)? If so, definitely say so.
• Feel free to criticize what we currently have! We want to hear your professional thoughts. I'd be happy to read a whole section in your proposal where you review the currently available documentation (as it pertains to your proposal) and say what you want to improve and why.

We are academics so when we read proposals we typically expect something along the lines

1. What is the current situation/what do we already know?
2. What is the problem/what is the gap in our knowledge or capability?
3. How are you going to address the gap? (key idea, methods, approach)
4. What will the outcome be? In which way will it improve the situation/our knowledge when it all works according to plan? (Why is the work important?)

If you can address some of these points then that helps us, too, to parse your proposal.

User profiles

• Very good idea!
• The scientists come in various levels of experience and but I consider this multi-dimensional: experience can range from beginner to expert in the subject matter (MD and analysis), Python/programming, use of MDAnalysis or other tools.
• When they used other tools it can be helpful to say "if you did X in tool Y then this is how you do it in MDA". There's actually a nice review we can link to [1].
• Administrator can be an actual computer admin or someone who plays the role of admin even it is not their main job; for instance in academia, graduate students often look after computers as admins.

Quick Start

• Good idea to tailor them to the audience.
• We definitely need to include the conda installation.
• It would be great to have a quick start that explains the common case for how to set up a full installation on a cluster/supercomputer. Essentially, this works just fine with conda but it's a common requirement so we should make clear how easily it can be accomplished.

Beginner tutorials

• Add a list of five (or less, see below) tentative topics; this would be better than saying "we'll figure it out as we go along". Better to have a plan and then change priorities based on new insights than just improvising the whole way through.
• Visualizations should also include molecular images of the systems (e.g. created with VMD. A while back I wrote a very simple VMD Tutorial for a class, so we can teach you the basics of molecular visualization quickly – it's fun.

Time

I don't think we need to make this an extended project and rather try to make it work in a focused manner. Perhaps we start with three beginner tutorials and add two as stretch goals?

References

1. T. Giorgino. Analysis libraries for molecular trajectories: a cross-language synopsis. In M. Bonomi and C. Camilloni, editors, Biomolecular Simulations: Methods and Protocols. Springer, 2019. preprint