Issues should be reconcilable

[jpmedley]

I should be able to make corrections by hand that create an updated version of the appropriate MDN file that I can then use as the basis of a PR to Browser Compat Data.

[mdittmer]

This is possible, to an extent, on the firebase-and-server branch:

npm install
npm run build
firebase serve

Separate terminal:

node main/server.es6.js

Visit localhost:5000/multi.html. When you select an item in the compat data collection and click the edit (looks like a pencil) button, you get a JSON view based on current MDN compat data master, that is cursor-positioned and scrolled to the interface member you selected. You can edit it, then copy/paste to your editor.

This flow needs work, but it's an initial attempt to get into the context you care about and start making changes.

[foolip]

@jpmedley, I'm not sure I understand this issue. Is it the issues in the bottom-right corner that you think should be possible to correct by hand somehow? Or do you mean that given a list of issues that affect an interface, it should be possible to get the JSON fixes for only a subset of them, as opposed to an all or nothing approach?

[jpmedley]

I thought I was recording what we discussed, saving changes to a particular API.

[foolip]

OK, so this issue is roughly the same as #9, i.e. the ability to have the differences between Confluence and MDN be reconciled by producing new MDN JSON that would match Confluence. Downloading that or getting the JSON in a textarea would do the trick, right?

Do you always want all differences relating to a particular interface (JSON file) to be reconciled at once, or is there some granularity needed?

[jpmedley]

I may need some clarification. I don't how how something could get reconciled if a user hasn't hasn't touch it. And if a user touched it, it would need to be saved.

[foolip]

I'm trying to not assume anything about what the UI or workflow is supposed to be, because you know what you need, and I'm just guessing what I'd do in your shoes. The only bits that are really clear to me are:

1. Input 1: current JSON from https://github.com/mdn/browser-compat-data
2. Input 2: confluence data from (derived from https://github.com/mdittmer/web-apis)
3. Those go into a black box
4. Output: A PR on https://github.com/mdn/browser-compat-data with changes for one or more JSON files, which will be reviewed and merged by MDN contributors

It is possible to do this without having a web UI at all, by just assuming that confluence is correct about everything, and returning JSON that would make MDN agree. So the purpose of the web UI must be for the output to be something other than the JSON with all differences reconciled, so either just a subset of the problems fixed, or with some manual changes.

Here's my strawman MVP: a script that reads in a browser-compat-data JSON file, updates the data to match everything we know with confidence from the Confluence data, and then saves the result to the same or another JSON file. (Creating a PR from it would be done separately.)

Would that do the job? If yes, one could still of course wrap it in a web UI so that people don't need to install the script on their machine to use it.

If there's anything more than this that is needed to work effectively, I'd like to understand the ideal work flow.

[jpmedley]

"It is possible to do this without having a web UI at all, by just assuming that confluence is correct about everything, and returning JSON that would make MDN agree." No. MDN contains many notes that would not be in Confluence. We don't want to overwrite those. If you've clone MDN's DB run: grep -r -n "notes" ./ "Here's my strawman MVP: a script that reads in a browser-compat-data JSON file, updates the data to match everything we know with confidence from the Confluence data, and then saves the result to the same or another JSON file. (Creating a PR from it would be done separately.)" This is close to what I've been trying to get from the beginning. For reasons already stated, I don't want to risk overwriting thins in MDN that need to be kept. The guys over at MDN would no doubt reject any PRs that did that. Joe Medley | Technical Writer, Chrome DevRel | jmedley@google.com | 816-678-7195 *If an API's not documented it doesn't exist.*

…

On Thu, Mar 1, 2018 at 5:34 PM Philip Jägenstedt ***@***.***> wrote: I'm trying to not assume anything about what the UI or workflow is supposed to be, because you know what you need, and I'm just guessing what *I'd* do in your shoes. The only bits that are really clear to me are: 1. Input 1: current JSON from https://github.com/mdn/browser-compat-data 2. Input 2: confluence data from (derived from https://github.com/mdittmer/web-apis) 3. Those go into a black box 4. Output: A PR on https://github.com/mdn/browser-compat-data with changes for one or more JSON files, which will be reviewed and merged by MDN contributors It is possible to do this without having a web UI at all, by just assuming that confluence is correct about everything, and returning JSON that would make MDN agree. So the purpose of the web UI must be for the output to be something other than the JSON with all differences reconciled, so either just a subset of the problems fixed, or with some manual changes. Here's my strawman MVP: a script that reads in a browser-compat-data JSON file, updates the data to match everything we know with confidence from the Confluence data, and then saves the result to the same or another JSON file. (Creating a PR from it would be done separately.) Would that do the job? If yes, one could still of course wrap it in a web UI so that people don't need to install the script on their machine to use it. If there's anything more than this that is needed to work effectively, I'd like to understand the ideal work flow. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0vizgFPYJXXOBdl-3qwny9DZKf2lOBks5taKG6gaJpZM4SYuWi> .

[foolip]

My strawman there does mean preserving everything in the JSON that we don't explicitly modify or remove in order to match. (To generate the JSON from scratch as opposed to read+modify+write would of course destroy data all over the place, so let's not so that.)