Consultation and governance

1. What is the use case being addressed?
2. What are some ways to facilitate the behaviour?
3. What is the most flexible approach?
   • Will it prevent the ability to deliver a corporate brand?
   • Does it break existing functionality?
   • Is it of general use beyond a particular “specialist area”?
4. What is the most technically compatible way?
5. What should it look like?
   • Is it good best practice (technically, visually, UX)?
6. Who will implement, how “expensive” is it?
   • We encourage code contributions

We aim to produce consistency and clear guidance on best practice. We also want to revise existing components to share lessons learned.

1. Quarterly virtual meetings
   • Agenda-driven discussions
   • Discuss changes that have already occurred, and new requests
   • Establish goals, priorities for next period of time
2. Decisions stored in the VF documentation
   • What was agreed
   • Why it was agreed
3. Document and circulate
   • Conversation on GitHub issues
   • Discussions and ideas on Slack

At a high level it follows this flow diagram.

Who

• VF core maintainers
• EMBL Communications' Digital and Design teams
• EMBL-EBI Web Development, UX and Communications teams
• Nominated service representatives
• Relationship with EMBL-EBI Web Guidelines Committee
• The requestor(s) of a new component or change

When

In addition to the quarterly consultation, we meet on regular basis in three channels:

• Design consultation, every other Monday
• UX consultation, every other Tuesday
• Technical consultation, monthly on the first Thursday

These form initial discussion and debate on new ideas before they are further tested and actioned on the GitHub issue queue.

If you have an idea you'd like to suggest, the best places to begin are:

• raise the topic on Slack
• create a conversation on GitHub
• If you have a more formal request, you can email it to ken.hawkins [at] embl.de.

In any case we'll help you convert it to an actionable proposal for the correct group of consultation.

The Visual Framework allows "local rule". You won't be blocked from adding and overriding components.

If an agreed implementation doesn't cover your needs, you can still:

• use the Visual Framework accommodate customisation at the edge (in Sass or JavaScript) or core changes (by bringing your own build process or design tokens)
• you can create and use a custom component in your local project and share the component on npm for others to use

If you need help understanding how to do this, reach out to the community on Slack or GitHub.

We work to avoid entropy and fragmentation of the VF through a consultative process that has been proven to work with the VF 1.x.

We strive for an inclusive process that guides the 300+ developers to make the right decisions. We avoid being website police — we know past experience that we neither have the resources to monitor all sites nor can we force services to do a re-development.

• we move forward with the VF as one system with many implementations
• the VF is as good as it can be
• we have a record of how and why things change
• we want bring more sites into the fold

We remain mindful to support communicating, collaborating, engaging.