Open kytrinyx opened 8 years ago
This may be an opportunity to do (and I imagine it will require) some refactoring. It seems a completely different mode of operation because instead of iterating over all the tracks and checking if they have a certain exercise, it's iterating over a single track's exercises. Of course the pieces in common are that they'll both have a dry run mode and they'll both have the component of posting the actual issue.
Also a design question to address: I think it likely that the -track
mode we will want to prepend the exercise slug to each issue posted, so as to be able to differentiate them. I don't anticipate needing to make that configurable. Any need to make the body configurable as well? And how would that work? We may need to have have the initial version be non-configurable and just write the body in a generic way.
It seems a completely different mode of operation
Yeah, I think you're right that it's pretty different. The endpoint is GET /v3/tracks/:id
, so http://x.exercism.io/v3/tracks/go, for example.
we will want to prepend the exercise slug to each issue posted
Agreed, I think we should just stick it in the title, and not worry about changing the body (until we realize for some reason that we actually need it).
See https://github.com/exercism/xgo/issues/275 for the original discussion
Sometimes we want to survey every single exercise in a track for a particular problem. Having one issue per problem makes it much, much easier to do this, because we can load-balance across maintainers. Also, other contributors might come by and tackle one or two.
Sometimes checklists work, but my experience with checklists for exercises in tracks has been less than convincing. We're always forgetting to check them off; there's no way to reference a checkmark directly from a commit message or PR message.