aimee-gm
commented
4 years ago My feedback at the moment (given I'm new here 😄)
:+1: to remove superfluous code. It detracts from the purpose of this project and makes it confusing to add new test cases. The emphasis should be on encouraging good tests, and those files are all that's needed.
:+1: to CI, and linting the JSON/HTML files. Although we could introduce something like prettier that would reduce the need for linting and even be run on a pre-commit hook. Perhaps we would just need to verify that the JSON & HTML are valid, though? But, we may want to add test cases for invalid HTML at some point? 😉
:-1: to publishing to each individual package manager. All it takes is for one auth token to become revoked accidentally (or intentionally) on one of those platforms and it'll become broken, and unlikely to be fixed unless you have maintainers active (and in an organisation) on those platforms. I also don't see any demand for it at the moment.
:+1: to issue and PR templates, would be massively useful in helping people contribute. I would rather that updates were made here than my own parser, for example. Making this repo friendly to new people would benefit other parsers, too.
:+1: to ditching the change-log, it's another barrier to contributing.
Thanks for this write up and ideas!
Zegnat
Hello, all!
Spurned on by @aimee-gm's #118 and the ensuing conversation in #microformats chat, I'd like to open this discussion with some thoughts on we might improve this project and repo for its users.
At a high level, this project provides a set of input (HTML) and output (JSON) files for microformats parser developers to test their projects against. The core focus of development on this project should be in improving the quality, breadth, and depth of those inputs and outputs. They should reflect the consensus of the community and its documentation (the wiki, mostly).
My strongest opinion is that anything beyond those inputs and outputs is superfluous to the primary function of this project and should be removed from the code. This would include the Node.js-specific code, CSS, etc.
Now, that's a very strong opinion, so I'll propose a few alternatives as well. 😄
Continuous Integration
Configuring continuous integration has been brought up before (#88) and came up again in chat. In my mind, we'd use CI for a few things:
masteras a "release" (maybe using the datetimeYYYYMMDDHHMM?) and pushing that tag to GitHubThe latter is more useful if we create language-specific packages in this repo. @aimie-gm noted this in #microformats chat:
Which brings us to…
Language-Specific Packages
We could use this repository to build and distribute language-specific packages (Node.js packages, Ruby gems, Python packages, PHP… things ). That'd get us into mono-repo territory and would introduce some organizational challenges, etc. But… it's possible.
Google does this with their Protocol Buffers repo. It's not impossible, but would def. add some overhead. A
CODEOWNERSfile would come in super handy in this case. We'd then use CI to generate, tag, and push those various packages to their distribution sites.Meta
A grab bag of things we could add to this project:
CODEOWNERSfile (helpful for PR reviewers, etc.)change-log.htmlfiles in favor of relying on the Git commit history (which truthfully does the exact same thing…)…that's what I've got right now. I'm excited to hear your feedback. Thanks for reading!