You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think this requires a little planning before we finalize it, but at a high level, I think we want to make this repo so it is useful, defensible, extensible and self contained.
In terms of cleaning up our file tree and history, I think that means a simple folder and file structure, along with good documentation.
I suspect this would mean that old stuff is in an archive branch if needed, or is in GitHub history, and that new stuff is named in a clear and concise way. We also of course want to note if any external systems need to be updated to account for the changes being made.
This is ready to merge when
We have a good plan for cleanup
The plan is executed including documentation and branch or archive management
External dependence are tested to be safe or resolved
The text was updated successfully, but these errors were encountered:
One of the other dimensions to this is cleaning up the branch, issue and PR setup that we have now. There are a lot of branches we are never going to use, and those should either be removed, or integrated in a meaningful way depending on the status of the work they relate to.
Having thought about this a little we seem to have 3ish parts:
a local and human readable record of tasks and ratings (e.g., the task-map.csv, and the task.mds) that is organized, clean etc. I think we are close to having this, but need to do some cleanup on MDs, work out a good template for those, and make sure they all have the correct content e.g., Paper URLS in task MDs #373.
a local and machine readable record of the same (e.g., a tasks.csv or tasks.json which makes all our mapping data something that can easily be ingested by other services. This presumably would be the data representation that is used to create 1 and also 3, and more generally in Making mapping extensible #372.
a platform for interpreting mapping data (and perhaps displaying synergy results eventually too). This would presumably start out as an observable UI and end up something we can host, similar to the cycle we had around the COVID dashboards. There's a lot of decisions to be made here and a bit of design work, so I think we should try to have a good pipeline for solving 1 and 2, so that we can iterate quickly on this step.
I think this requires a little planning before we finalize it, but at a high level, I think we want to make this repo so it is useful, defensible, extensible and self contained.
In terms of cleaning up our file tree and history, I think that means a simple folder and file structure, along with good documentation.
I suspect this would mean that old stuff is in an archive branch if needed, or is in GitHub history, and that new stuff is named in a clear and concise way. We also of course want to note if any external systems need to be updated to account for the changes being made.
This is ready to merge when
The text was updated successfully, but these errors were encountered: