Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detail the constraints that inform our work #221

Open
dotcode opened this issue Mar 16, 2018 · 1 comment
Open

Detail the constraints that inform our work #221

dotcode opened this issue Mar 16, 2018 · 1 comment

Comments

@dotcode
Copy link
Contributor

dotcode commented Mar 16, 2018

We need a section of the playbook explaining what our constraints are, in order to answer questions such as "why do you appear resistant to frameworks?"

Topics we should cover, among others:

  1. Accessibility.
  2. The law (ADA, 2010 Equality Act, GDPR, whatever informs our work).
  3. Our customers (amongst others, educational institutions with specific requirements relating to the above points).
  4. Maintainability (we maintain sites over decades, meaning we place emphasis on web standards - that are expected to be relevant for much longer time spans than a specific framework).
  5. Multiple product teams (as FEDs we need to share work across product teams, hence the need to crosscheck stuff with other FEDs - part of the reason for our use of PRs, and also informs our need to standardise on tooling/practices etc).

There are lots of techniques already detailed in the playbook. Now we just need to explain why we have chosen them.

As ever, do not feel overwhelmed by having to write the entirety of this in one go. E.g. if you're able to contribute only on the topic of accessibility, submit a PR with only that, and let someone else handle the rest.

Also there is no need to duplicate content - i.e. for accessibility there is no need to duplicate stuff already existing on our accessibility house style page, just link to it. All we need is stuff along the lines of:

Because of our need to develop accessible sites [link to relevant page], we regard as suspect any framework or tools that require extra or unusual work to make them accessible. For instance idiomatic code for some frameworks' allows or even suggests the use of non-semantic html. In this case we know that places a burden on us to train up every new developer to use this framework in a non-standard way, to avoid the use of non-semantic html.

Or something. It's Friday, I'm busy, I'm typing this in a rush and I've probably worded this horribly. You get the gist though?

@jpw
Copy link
Contributor

jpw commented Mar 23, 2018

I assume this will be a "for public consumption" and FED-focussed take on our internal WIP constraints docu?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants