Skip to content
This repository has been archived by the owner on Apr 16, 2020. It is now read-only.

Should we remove this repo? #24

Open
autonome opened this issue Aug 14, 2019 · 7 comments
Open

Should we remove this repo? #24

autonome opened this issue Aug 14, 2019 · 7 comments

Comments

@autonome
Copy link

I've started a few times now to file issues for Project Operations WG Q3 OKRs and other things here and keep stopping... it doesn't feel right to file issues spanning so many different areas all here in ipfs/project-operations. It feels like yet another different place people from a number of different areas would all have to start watching, etc.

We also have ipfs/team-mgmt, which seems to already be a home for very similar types of issues. Maybe that would be a better home for anything we'd do here?

Hm, another thought is to put all Project Operations WG work, and even all OKRs work currently happening in ipfs/team-mgmt, in ipfs/ipfs.

This would have the benefits of:

  • Increased visibility into how the project operates
  • Increased visibility into what we're working on
  • Increased visibility into what we've accomplished
  • Reduced number of repos for people to track
  • Easier to know where to participate
  • Project appears to be as active as it truly is

@momack2 @daviddias thoughts?

@autonome
Copy link
Author

Semi-related happenings in ipfs/team-mgmt#850

@momack2
Copy link
Contributor

momack2 commented Aug 19, 2019

I don't know where else we might discuss/track things like communications, maintenance, etc - but I agree this is a pretty sparse repo and we haven't been using it much to track our work. Historically, we have been very dating about using IPFS/IPFS because it sends an email to so many people for every new issue, and therefore isn't a good fit for day to day operations work that would flood a subscribers inbox. Things I foresee living in this repo include top-level plans around 2020 planning, comms checklist, event support, etc - those could likely be tracked in team MGMT instead, but would be a little harder to track as part of this wg discussions

@daviddias
Copy link
Contributor

Historically, we have been very dating about using IPFS/IPFS because it sends an email to so many people for every new issue

Exactly, this has been the main reason why we avoid using it unless we want to broadcast something to the entire community

Things I foresee living in this repo include top-level plans around 2020 planning, comms checklist, event support, etc - those could likely be tracked in team MGMT instead, but would be a little harder to track as part of this wg discussions

We also have had a practice of having one entry level repo per Working Group as described at https://github.com/ipfs/team-mgmt/blob/master/TEAMS_ROLES_STRUCTURES.md#expanded-description

We can consider, as suggested, to collapse this repo with team-mgmt. That would mostly mean two things:

  • Less repo jumping -> better discoverability
  • Every Working Group would get more notifications given that everyone follows team-mgmt.

In favor of reducing the notification overhead and improve on discoverability, it seems like something sensible to do.

@jessicaschilling
Copy link

Bumping this thread. @daviddias' suggestion for merging the content here into team-mgmt sounds best. @daviddias @momack2 @autonome ... are any of you willing/able to take on the migration at some point? Thanks!

@momack2
Copy link
Contributor

momack2 commented Apr 7, 2020

I'm in favor. @bubbi77 - can you handle merging this content in to the team-mgmt repo?

@jessicaschilling
Copy link

@bubbi77 - let me know when you're done, please, so I can check it off our audit recommendations! 😊

@daviddias
Copy link
Contributor

@bubbi77 I moved all the issues to the other repo (just in case you didn't have admin to do it). Now you just need to move the contents :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants