Suggestion: [Org / PM] Meta Repositories to support & encourage better PM

[DennisSmolek]

Problem:

• Right now the organization has many projects in rapid active development, but no place to converse, track, share, or manage things.

• This lack of structure and oversight is leading to a general state of confusion, even amongst very well intentioned, active contributors and managers.

• Users struggle to engage with the project and don’t benefit from cross communication/standards

• No clear space for Public "Clean" repository and "Messy" working dev space/notes, guides, outlines. Everyone uses their own thing..

Effected Departments/Orgs/Teams

• Tasks
• Schedules (Calendar)
• Releases
  • Milestones
  • Project Milestones
• Documentation
• Deployment
• Design Systems
• Repo Issues/bugs
• Responsibilities
  • Ownership
  • Decision Authority
• Goals
• Roadmaps
• Etc.

TLDR Solution:

Create “meta” repositories to act as DevGroup boxes

Create Project Templates for Project Owners

Key issue:

The Paradox of Choice:

There are simply too many ways, tools, preferences, services, ideologies to do things. Everything integrates with github but no one knows what the “right way” is to do anything. And most things are FREE

The Obvious Decision:

• Everything is on Github, and as public project nearly all github features are free and supported.
• The org can roll out/add structures and support as the Project Manager needs/asks.
• Github themselves pushes the uni-repo mentality and framework heavily.

Why that doesn’t actually work:

Public repositories are treated as up-to-date snapshots of the life of the project. Most devs IMMEDIATELY look at a few things:

• Number of Open Issues
• Last Commit to main
• last Release
• Header of the Readme.

Github knows this:

---

However...

GITHUB PROJECTS TRACKS ALL ACTIVITIES AS ISSUES

This means every small task, request, etc adds to the repo issue count. Long running discussions, or super issues (holder of others) gets seen as backlog/bad management

A Few more pains

Dev’s cant have freedom to discuss options because any concept on the main repo issue becomes “the devs real opinion”

There are many downsides I can list later if needed**

Consider writing docs for all the functions/methods in the codebase.

You could automate a task to use JSDoc and use a template to create the project management for the function and its docs page creation.

In a PM tool that would look something like:

In GIthub’s issue tag this would look like 30ish issues per function...

Talking hundreds of issues..

much pain...

What are people doing about it?

In the 3 groups I’m working with and in all the channels I’ve seen its usually

1. everyone forks the repo...

2. . . .

3. Profit....

But seriously,...

• the “dev box” of projects is going on private peoples forked copies, and OFTEN not the project manager/owner.

• This causes A LOT of hesitancy/uncertainty for people to know how to contribute.

• No one knows who’s responsible for what or what the status is for anything

• there are no milestones

• There are no outlines

• goals aren’t clearly defined...

• REALLY amazing documentation is in THE WEIRDEST place

(The best outline and explanation for Leva’s plugin system including skeleton examples, is in the Type definition file.... It’s better than the readme and example project has no docs)

Proposed Solution

Option 1 (Best IMO)

Use Github Projects (Beta) with custom views

Projects are no longer repo specific, issues require a repo to live on

Create a general pmndrs/DevGroup repo. & Project

(Highest Role restrictions)

• Central Hub for all the entire org

See Full List...

• This can be the future house of the design system/guide
• Can be the home for the website template/system
• General Org dev standards can go here (code conventions, semvar, deployment)
• Assets for other projects ( Like the Vike sandboxes, deployments to other guides, or assets from partnerships) can be stored & Managed centrally
• Issues, Milestones, etc dont matter.

Create a DevGroup or “meta” or whatever name repo for each project

(lower Role restrictions)

• Easy to point to central place for each project
• Project Managers have direct permissions to add/remove contributors

See Full List...

- Issue count doesnt matter - KEY POINT. Dev boxes are temporary.*** - Ideally between milestones which should be releases or a feature, this keeps the main repo the center of truth - Give contributors higher level access - They feel more important & invloved, & RESPONSIBLE - contributors can close issues - Owner can put resources on it and they can PR to it, but a - Milestones dont have to directly relate to the codebase.. Can be a feature set, or some other goals - Users don’t get confused about those milestones or why issues are left open for a year - I can go on and on

Option 2

• Create a DevResorces repo as in Option 1

• Create a general DevGroup repo to hold all issues/pm related things

Reason I don’t like this as much:

In the projects you would have to add tags to the issue to see them on a per-project basis This means every small task would have to manually get the task added this will add up, and people wont make tasks... Too much in one space

"Ok so what do we need today a big outline or something?!?"

No, no reason to make it drawn out or crazy.

1. Figure out the names. In the past I'd call it "Meta" because its still all public but Facebook ruined that word for everyone.. "DevGroup" seems ok

2. Create pmndrs/DevGroup. use it for shared stuff

3. Create a project for the org that's admin/owners

4. Then any org project can be made and assigned

5. Create 'DevGroup' repos for the projects with teams, put a issue in the project

6. Create a Generic Project for that repo

7. Assign the Project Manager as a Admin so they can invite other members to their "dev group"

8. Let them work the rest out

Why not ask them first? People are weird, and theres so much going on if you ask them to set something up they probably wont or wont get around to it Make the repo, make them an owner with the project. If they REALLY dont want to be organized or have some other method, they can request it be deleted..

** You can/will have to create public projects, but I think project members have to be inited **

Wow this was a brain dump.. LMK what you think and if you have a different opinion or better solution! This is just what's been bouncing around in my head

[gsimone]

1. generally sounds like a good plan
2. working group is the usual term i see used around, would that work?

[stephencorwin]

Interesting take. I definitely agree that milestones and roadmaps are useful. In terms of "no place to converse", we have a very active discord.

[DennisSmolek]

In terms of "no place to converse", we have a very active discord.

Hey Stephen, I'm actually super active on the discord, I was out sick for most of last week, but you can find me all over the place either trying to help or trying to learn.

These are just a few of the things I mean about "a place to discuss"

• In many cases the discord moves very fast and not all team members are in the same timezone, so discussing a particular issue becomes problematic and a game of catch up most times.

• I'd like a place to go over the schema of something very focused, and be able to refer to it much later. But if I do this as an open issue, suddenly I've got a 60+ day old issue, or something w/o a milestone, etc. It's not official enough to be a wiki, but it's not necessarily a problem. So what happens is there's usually random google docs flying around with links or it disappears. And say a new contributor comes along, they can never find it...

• Another issue is when discussing breaking changes or brainstorming, eager devs or those just learning sometimes take them as "cannon" or "upcoming changes" so maintainers sometimes fear discussing even the idea of things on the standard public issues.

• A real world example of this, a very well known company has many commonly known problems and is actively working to address them, but as a startup/small company they are afraid of making a promise or setting a deliverable and not being able to fulfill it. So afraid in fact that they've become almost radio silent on things.

  So a working group can set milestones more generically/relatively without the commitment..

• as Docs are actively submitted, reviewed, and discussed in PR's. But maybe you want to discuss two pages, or the idea of a merger, or a simple format question, work on a sandbox issue, etc. To do any of that you have to make a fork, do a PR, etc. Or maybe you ask on the discord and it gets missed.. So the question never gets an answer, you were waiting on it to even start working, you didn't write it down, and now two weeks went by and no one knows anything was happening..

There's tons more, and the vast majority of these things are things I'M PERSONALLY guilty of, let alone seen others do..

I don't expect to solve all or even most of these kinds of issues, but I think having a base "You can put that there" or "heres where we can put things in progress" would be enough for most people to (hopefully) solve it on their own