Setting up wireframe project

Hi,

During our call on Monday, we started discussing where and how to set up
the repository/ies that would host the wireframe project we've sketched up.

Here is what I understand our requirements to be - please comments on
additional requirements and/or priorities:

A. it should be easy to find all the derivations of the wireframe
project across languages/frameworks

B. it should be easy to add new language/frameworks to the project and
to welcome maintainers for them

C. it should be easy to welcome contributions to the project

D. the project should align its communication and authoritativeness with
guidance from FIDO & W3C - in particular, there probably will need some
oversight on how new variations get accepted in, and some way to ensure
continuous monitoring



As a point of comparison, TodoMVC which we've alluded to several times
as a similar approach to what we're trying to do:
* they have a central web site which lists the different variations
across languages and frameworks
  http://todomvc.com/
* all the variations (and the web site itself) are hosted in a single
repository (itself hosted by the tastejs github org)
  https://github.com/tastejs/todomvc
* there is a maintained test suite to automatically check that all the
variations are functionally identical
  https://github.com/tastejs/todomvc/tree/master/tests


My assumption is that we will be using one or several github
repositories. There are two broad approaches I can envision:
* this (these) github repo(s) are all hosted in a single github organization
* each language/framework decides how/and where they host their repo

With the single org approach, we would need to find or create a github
organization where adding new contributors and maintainers is easy (per
B and C above); I think @w3c on github probably matches this - I don't
know what rules govern https://github.com/orgs/fido-alliance - can
someone involved in FIDO comment on this?

For requirement A, I'm not sure @w3c is necessarily a great fit if we
use a multi-repository approach, since finding the N relevant repos
among the ~800 repos W3C host is not going to be optimal (although there
are ways around it). Probably not an issue if we use a single repo.

Creating a dedicated github organization (e.g. anchored in the Webauthn
Adoption Community Group - many other W3C Community Groups have created
their own org) would be another approach, if we can find a name for it.

If instead we let each language/framework community host their own repo,
the challenge becomes in ensuring consistency across the many different
places - there may be a solution using e.g. github actions to preserve
confidence in this more distributed fashion, but this probably needs
more thinking and experimentation.


For the testing of the different language/frameworks variations (per
requirement D):
* I assume we want the testing to be mostly automated - not sure how
easy that will proved to be across many languages / frameworks

* I assume the testing would be done through what gets exposed to a Web
browser (similar to todoMVC), but I don't know if we expect that to be
sufficient to our end goal; I don't know how easy it is to automate
browser testing when using different type of authenticators, but that's
probably a great question for our group to consider anyway

* if we use a single repo, the test run can happen as part of the
continuous integration check on pull requests (à la todo mvc)

* if we use multiple repos (in a single org or across multiple
accounts), we probably need to set up a shared github action to simplify
the deployment and maintenance of the test suite

Another impact of requirement B and C is that we need to find the right
open source license for the project; todoMVC is using an MIT license,
which I would suggest we go with unless there are good reasons not to.


Summarizing:
* we need to figure out one repo vs multiple
* we need to figure out centralized or decentralized management
* if centralized, we need to figure out what github org will be the best
match
* we need to agree on a license
* we need to start thinking about our automated testing approach

Dom

Received on Wednesday, 20 May 2020 09:09:24 UTC