[WIP] Add project management documentation

[malteserteresa]

This can be found in the PROJECT_MANAGEMENT.md file

TODO

• Add dev - designer - user flow suggestions
• Add feature request -> requirements flow suggestion

[djbusstop]

I wrote some PM things I learned, and how I'm doing stuff for web extension. These don't need to go in the docs exactly as written. But could help the docs. I don't know what the best way to organise these things or how specific we want to be.

Types of open meeting:

• Sprint planning - In first week after a release, to get people to take ownership for tasks for the next sprint, and see what needs more info for people to do it
• Check In - Like a stand up but biweekly. To make sure tasks assigned at sprint planning are moving smoothly
• Planning - Where we talk about bigger issues that require people across multiple teams. We break these in to smaller tasks and see what depends on what in order to get the task ready to be developed when it's time for it to go in the sprint.

Workflow for normal sprint:

• Create issues on github (as a result of a planning meeting, or they are created at any time)
• Manage the issue meta data and information as much as possible before the issue is ready to be handled in this current sprint. (This is done in a sprint planning or planning meeting)
• Put the issue in the github project board when it's in the current sprint (this can be seen by the milestone on the issue)
• Make sure in check in meetings that these issues are progressing
• When the sprint changes, clean up the workspace
• Have a sprint planning meeting to decide what goes in workspace again 🙂

Product management lessons:

• Have meetings mid sprint to talk about issues for the next sprint. This helps stay ahead when it comes to specs, that they are ready when it's time to start working.
• Remind people about meetings
• Host a retrospective to reflect with others on how this system is working.
• Someone needs to take ownership of a board. Probably the same person hosting the meeting to make sure tasks are progressing. But without ownership, the board gets outdated and just is cluttered.

[djbusstop]

I don't know if a bug necessarily becomes a feature implementation. I think it's fine to leave an issue as "bug". Cuz fixing bugs isn't implementing a feature. So I guess I would just change this by removing the words "Bug and-" from the begnning of this sentence.

[lucie-docs]

Agreed. Bug fix and feature implementations are two different things. Also this type of info is specific to each repo so I deleted it from the CONTRIBUTING file.

[djbusstop]

I have never seen this before? I am used to having WIP removed as the indication of status. In the browser extension board there is a lane for review. I would use this as the best place to show the status.

[lucie-docs]

This is the workflow for the data team actually, see "Working on a modeling issue" section here. I think we shouldn't generalize the practices of one team to all teams. Also I deleted this info from the CONTRIBUTING file as this is very specific to the people who want to contribute code and this repo should contain information on how to contribute to the project generally. Let me know if the new CONTRIBUTING file covers all cases.

[djbusstop]

Eep um I would much prefer a link to my github than just my name. I want to change the name of my github anyway, away from my legal name

[lucie-docs]

Also @malteserteresa you mentioned in Slack that you put only the people who had their portraits on the website in the docs but River is not on the website. Should we just do a poll in Slack to ask who wants to be in the docs and if we should use our real names or only our Github names?

[lucie-docs]

I have deleted the names in the new version of the file. My idea is that we just explain our structure in this file and then in each repo README, people can add themselves if they want and how they want in a "Repository management" section. See this branch as an example.

[djbusstop]

Same comment as above regarding this topic: advise to remove "Bug and". But also this is duplicate info. Which would be hard to manage. Maybe use this file as the source of truth? Not sure,

[lucie-docs]

I will delete this from the PROJECT_MANAGEMENT file which will contain only general information about the team project boards and our sprints and meetings.

[djbusstop]

Same as above

[djbusstop]

Use bullet points * or -

[djbusstop]

I have written about this in my RFC regarding feature spec

[djbusstop]

I noticed the updates. I have some feedback here that is more general:

I gave some feedback to the project management points and how I've been doing it for the web extension "team". But perhaps different groups want to use different patterns? The system I'm using is what I'm going for because it makes the most sense for me when I call meetings. But other people might use a different structure and that can also work really well. I would be hesitant to try to apply the extension development structure to other teams too early? Maybe it's too soon to refine the processes for the whole group down to reproducible parts? The people who take the initiative to call meetings would probably be better off with doing it the way it works for them rather than needing to refer to more documentation.

Also, this is a lot of documentation and I dunno if people will read it. I worry it would slow them down.

[lucie-docs]

Hi @malteserteresa, is it ok to pull your branch and directly insert corrections in there? I would like to restructure the information as it seems it is duplicated in two files and I'd also like to make the content shorter. @river-honer: I would take the comments you have already left into account of course. I just need write permission on this repo :)

[lucie-docs]

Also, FYI: I'm writing a piece for the blog and I would like to link our holocracy manifesto in there :)

[djbusstop]

@lucie-docs You can refer to this RFC as well opt-out-tools/opt-out#110

[lucie-docs]

@malteserteresa Chatted with River yesterday and turns out I have write permission on this repo :D So all I really need is your permission to directly modify the structure of your content :)

[malteserteresa]

@lucie-docs of course :) go forth and document!

[lucie-docs]

@malteserteresa and @river-honer, I've started shuffling things around and rewriting some files. Please check the following files directly in the branch: README, CONTRIBUTING, ORG_STRUCTURE, ROADMAP.
And let me know if this is going in the right direction!
I still have to work on PROJECT_MANAGEMENT + VISION_&_TOOLS after that.

[malteserteresa]

@lucie-docs honestly it reads so great now, just a one thing, Anna sadly no longer can be in the team so can you remove her from the contributing.md

Also I'm just wondering where we should put the diagram of the OOT architecture and a description of how the repos work together @river-honer do you have any ideas?

[lucie-docs]

@lucie-docs honestly it reads so great now, just a one thing, Anna sadly no longer can be in the team so can you remove her from the contributing.md

Also I'm just wondering where we should put the diagram of the OOT architecture and a description of how the repos work together @river-honer do you have any ideas?

Aw no, are we designer-less again? :( I was thinking of putting the diagram in our backend repository with the explanation of the OOT architecture. Is the diagram actually up-to-date?

[malteserteresa]

Yeah sadly :( after the Mozilla plug we'll do another "recruitment" drive