My suggestion for web sprints below, will make a start on this next week. If you think you're a stakeholder in unMonastery web stuff, or you want to working on unmon web stuff, reply to this thread.
@katalinhausel without stopping you Getting Stuff Done, it would be useful to roll your needs for Athens WP into this.
Backlog is here: https://docs.google.com/document/d/1mx86wp_OVe-ZM9wNIo4oAmkSzBbot-Nw8g6J3pibDhY/edit
- I added headers to delineate distinct projects (although there may be some overlap in requirements between these projects)
- Where necessary I add a 'Requirements' section to make it clear the purpose of each project
- I have added my suggested idea of a 'Sprint' which contains well defined pieces of work, and has a bunch of people who commit to it who can do the stuff required for that sprint
OO's for web sprint:
- The suggestion here is to allow Projects to be subdivided until there are small well defined tasks ('One task' roughly 2 hours. If it's more, break it down). Some tasks that fit a particular goal and make sense to go together can then be grouped into one 'sprint', people commit to that sprint until it is ready to go, then that sprint starts and doesn't stop until it's finished. The people who have committed make contributions when/as they can.
- The content of each sprint is decided on by all stakeholders in all current projects, so everyone can collectively determine priorities and make a sprint that best reflects what needs to be done next, and the abilities available.
- If a sprint stalls or fails, the stakeholders and people committed to the sprint can collectively decide to end it happily and prematurely and build/start a new one.
- A well defined 'Sprint' is exactly what we are working on now for all of our web projects, and we work on it until its done and nothing else is worked on (except emergency fixes/changes). People can add stuff to the backlog to their heart's content but if it's not in the current sprint, it is not being worked on.
- When the sprint is done, we congratulate ourselves, and design the next sprint from what is in the backlog.
- We need some very small very achievable pieces of work to get our confidence and momentum up, and whilst we transfer knowledge/skills/confidence about how everything works and how it can be worked on. We can achieve this with the first few sprints as small achievable sets of tasks, and limit ourselves to small sprints going forward.
- If this structure is accepted/useful, there's a gazillion Agile management tools we can put all the features and tasks in to make it more manageable, and to manage sprints if we find we want extra management abilities beyond a Google Doc. This might be useful because look at the difference between the website projects and the dashboard project: The website functionality is reasonably well understood and someone mainly needs to decide on content and design. The dashboard is still way in design/requirements analysis stage. Two different sets of features/skills are required to manage the stage these two projects are at.