Open joshblack opened 5 years ago
cc @tw15egan
I'd like to get a comprehensive document.
But also a "diplomatic" document. Which can really be a clear reasoning for why carbon-charts should not be in the IBM org (so we can at least drag it into carbon-design-system). e.g.- security warnings, lack of ability to pull down and replicate.
Ideally would like to have that piece so that we can move the repo by the end of this sprint (either me or @alisonjoseph to connect with Dean Williams first to explain).
Probably should do this reasonably quickly, as got a voicemail from Dean about hearing about this, and curious as to the justification.
I also think we could reasonably argue that core component repos are the only ones we want to put in /IBM org at this point.
@kuehndaniel - could you also weigh in here on some of the broader ideas for data viz solutions - with Accurat, etc?
The only ones that are under IBM are repos that have been approved by the Core Carbon team and adhere to a specific guideline. This one was not approved by the Core Carbon team, and thus should be moved under the Carbon Design System umbrella, like the current Data Viz repo, until it is approved. This is my understanding
We (I...) made the mistake when they came down for the workshop of accepting the idea of IBM/carbon-charts as something that we could use their solution for. So it's as much a diplomatic problem as an actual practical one.
Your response is absolutely right, we just need to have those guidelines a little clearer so that we can point out where it didn't adhere.
Here's some high-level notes:
CONTRIBUTING.md
should provide a way for anyone to pull down the codebase and work on it in order to submit a PR. One might run into trouble with the current repo because the guidance for running charts is out-of-date or does not work ReferenceCONTRIBUTING.md
that call out things for Pull Requests (like npm run lint
) will error out because dependencies are missingCONTRIBUTING.md
documentation also suggests commit criteria that is not up-to-date after viewing the commit history in the repo: https://github.com/IBM/carbon-charts/blob/master/CONTRIBUTING.md#contribution-process, namely the usage of emojisREADME.md
TL;DR the experience of consuming the packages need to be improved in order to be considered stable. This includes improving docs for contributing, from how to fork the project to bringing it down, running locally, and ultimately creating a pull request. In addition, there should be a greater attention to performance for teams that are using these components, which would require a smarter bundling strategy that using webpack to build the dist
folders that currently exist.
Perfect. I can flag that - especially because we're not saying any of those flaws are inherently wrong, merely that they are tests against which something "core" needs to pass.
As far as specific data viz planning, we want to take the original design language guidance and visuals (https://www.ibm.com/design/language/experience/data-visualization/) and update them to the new language. In time we would either code those data viz modules or teams from around the business code them and contribute back. I was hoping the WCE charts would be a shorthand to getting the base set of charts coded, but it sounds like that's not an option currently if the code doesn't meet certain standards. Updating the current charts is not a priority right now, but if we have guidance to give WCE they are open to taking on that work. Diplomacy is important, too.
@shinytoyrobots had the suggestion to create an internal-only document of an audit of the current carbon-charts project. This audit should contain the following: