Skip to content
This repository was archived by the owner on Feb 8, 2023. It is now read-only.

Decide where to track Project Roadmaps and configs for labels-and-milestones #276

Closed
flyingzumwalt opened this issue Nov 28, 2016 · 4 comments

Comments

@flyingzumwalt
Copy link
Contributor

In order to land the work in #257 we need to decide where to track

  • Generated Project Roadmaps
  • Configs for labels-and-milestones
  • Captain's Logs (if we generate them)

Please comment so we can proceed with this work.

cc @diasdavid @whyrusleeping @jbenet @RichardLitt @haadcode, @victorbjelkholm @lgierth

The Options

Configs for labels-and-milestones

Where are they Now?

As part of #257 I submitted some PRs to go-ipfs and js-ipfs with project-specific configs for the labels-and-milestones sync tool. Based on comments on those PRs (including my own) it seems that we don't actually want to store those files in those places. Where do they belong?

Where should we put them?

My sense is that we want to put the labels-and-milestones configs together in one repository that has the general configs for running the tool plus the configs for each project. I suggest putting them in ipfs/pm rather than creating yet another repository.

Generated Project Roadmaps

Where are they Now?

Currently the roadmaps are inside of each project's repository. Some of them are outdated. ie:

As part of #257 I submitted some PRs to update them with generated roadmaps.

Where should we put them?

@whyrusleeping mentioned on today's call that we might not want these files in the repo because it will add noise to the git log when we regenerate the roadmaps.

Option 1: Leave them where they are, in the main repo for their corresponding project
Option 2: Store all the roadmaps together in ipfs/pm

Captain's Logs

Where are they Now?

When we've published these, everyone seemed to love them. We can tweak the roadmap generator to generate weekly captains logs too (see haadcode/roadmap-generator#6). If we do that, where should the generated logs be stored?

Where should we put them?

Same options as the roadmaps:

Option 1: Put them in the main repo for their corresponding project
Option 2: Store all the Captain's Logs together in ipfs/pm

Note: Unlike Roadmaps, which we want to store as a single file that gets updated/regenerated over time, we will want to let people browse the full history of Captain's Logs (which are effectively changelogs for the master branch of the repo)

@RichardLitt
Copy link
Member

Putting the configs and generated Roadmaps in ipfs/pm sounds good to me. I agree with @whyrusleeping that the generated roadmaps will mess with the history and add noise. I don't think it's wrong process to put project management information here.

I think that the Captain's Logs should be in Issues in their respective repositories, because they don't have to be markdown documents, and linking in a README to a long-running issue isn't the worst thing in the world.

@whyrusleeping
Copy link
Member

I think it would be nice to have a separate page for all of these, something like pm.ipfs.io/go-ipfs where you can view all the roadmaps. It doesnt have to be pretty, just a nice place for them to live

@flyingzumwalt
Copy link
Contributor Author

@whyrusleeping that's a good idea. Regardless of where we store these config files and generated roadmaps, we could expose them on a page like that. Where do you think we should store the config files and the generated roadmaps themselves? Should we put all of those files for all of the projects into a single repository (possibly ipfs/pm for now)?

@daviddias
Copy link
Member

I like the idea of being able to access them at a place like pm.ipfs.io :) What I would like to see first (and this is kind of just notes from some of the discussions we've had so far):

  • Convert the scripts into a testable module
  • Make sure that there are no weird situations(i.e: milestones getting duplicated)
  • Enable migrations (i.e: milestone renaming)
  • Let project leads test it - At first, it is ok if the generated files are inside the project repos, I feel.

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