the potential in drupal 8.x and how to realize it

The potential in Drupal 8.x and how to realize it

Angela Byron, Gábor Hojtsy

1.Drupal 8: The dawn of new

possibilities

Making big changes in 8.x: It's possible!

Intro to semantic versioning

We are here

Predictable

Improvements every 6

months

Incentive to

contribute

Backwards-

compatible

2. What to improve?

"Top-down" goals (from committers)

Migrate UI

Configuration Management

Frontend testing

Media

Blocks and layouts

Workflow

"Bottom-up" goals (from community)

BigPipe

Contact for basic web

forms

Twig

Picture support

Admin style guide

Improved entities

www.drupal.org/core/roadmap

Angela Byron

Final screenshot

3. But… how?

Pain points from Drupal 7 and Drupal 8.0.x

Bikeshedding, especially of user-facing changesWork hard on something, may still get rejectedDirectional feedback vs. standards nitpicksDon't validate ideas until *after* shipping; now too

late to fixGiant core patch vs. sandbox vs. contrib vs. core

Jess M

I'd add something here about significant/disruptive changes going in without adequate architectural, usability, etc. feedback from maintainers (think the routing system merge).

Gábor Hojtsy

Not sure that kind of problem is addressed in this session honestly :/ Quality assurance vs. making progress on the system level. That is where branches would come in, I guess.

1. Iterate quickly and cheaply on ideas2.Clear sign-off points to avoid wasting time3. Involve the right stakeholders at the right time4.Gain visibility for proposals from committers5.Reduce barriers to entry into core for new ideas6.Clear visibility of priorities for the community

Ideas for improvement

How *other* people improve products

Possible implementation for Drupal core

Proto-

type

Core (experimental

)

Core (stable

)Build Idea

Plan

Refine

Spec Ship Gates

Angela Byron

Suggested refinement from Bojhan and yoroy that more accurately reflects "agility" of process.

Angela Byron

Also see following slides which break this down step-by-step.

Note: This is *just* a proposal...about how to make proposals. ;)

Your feedback needed!

Idea

Plan

Proto-

type

1. "Idea" is just a few sentences (lean UX-style)2. Get sign-off / rejection right away (product

management)3. To get to next phase, formulate a "Plan"

Plan template (beta)

https://www.drupal.org/core/initiative-proposal-template

For compelling 8.x minor releases...

1. Prototype iteratively, as cheaply as possible2. Validate prototype with real users3. Once validation occurs, the prototype becomes a

spec4. Now, No. More. Bikeshedding. ;)

Proto-

typeBuild

Spec

Who to talk to? At least some of these folks.Committer

sProduct Manager

sFramework

ManagersRelease

Managers

SubsystemMaintainers

Shortcut module

...

Field systemQueue system

Topic Maintainers

UsabilityAccessibility

PerformanceTesting

Documentation

Block module

MAINTAINERS.txt && d.o/project/governance

Initiative Coordinators

Content Workflow

...

Web ServicesMedia

Multilingual

Gábor Hojtsy

Was this meant to be practically the same as 15, since that has stakeholders and decision points?

Jess M

Or maybe to explain our existing governance at a high level? Slide 15 does not define what a "framework manager" is for example.

Angela Byron

Right, overview of governance as a whole. Took a stab at it. It's not easy. :\

1. Now, spec becomes core patch2. However, most "core gates" (except MVP testing! :)) are

bypassed3. Initially goes in as "Experimental" module4. Bikeshedding opens again after shipping. ;)

Core (experimental

)Build

Ship

Experimental modules

Pros ConsAlready in core

Can be less stable

Familiar core process

Easy for end users

Iterate quickly

Cannot commit directly

Needs reviewers

System-wide changes not possible

Risk of lingering technical debt

Jess M

In reply to the speaker notes: "we stopped talking about" meaning it was taken out of the presentation? I think we will still need feature branches eventually. Not everything can be in a single totally new module.

Gábor Hojtsy

No, not stopped talking about int he slides, stopped talking about them in general since we found ways around it so far.

1. Once iterated on a few times, move to "proper" core module.

2. This requires all sign-offs, core gates, etc.3. Radical refinements no longer possible without a new

experimental module.4. Enjoy!

Core (experimental

)

Core (stable

)Gate

s

Summary

1. Get sign-off/rejection *before* doing tons of work2. Validate direction with real-world data vs.

bikeshedding3. Make it cheaper/easier/faster to improve core all

around4. Jump through the right hoops at the right time5. …6. Profit! :P

4. What do you think?

Discuss!

Are the pain points addressed?Balance of bureaucracy vs. unpleasant surprise?How do we get ideas on the roadmap?What about the implementation details?

Jess M

In terms of the implementation details of getting things on the roadmap, I think people create plan issues and tag them with some tag that means "this plan needs review" and the relevant signoff tags. Once those signofffs are done & we approve the plan, we put a tag on it for "this plan is approved" and a committer adds it to the roadmap.

Join us for SprintsFirst-Time Sprinter Workshop - 9am-12pm in Room 271-273

Mentored Core Sprint - 9am-6pm in Room 275-277

General Sprints - 9am-6pm in Room 278-282

Friday, May 13 at the Convention Center

So How Was It? - Tell Us What You Think

Evaluate this session - https://events.drupal.org/node/9866

Thanks!

the potential in drupal 8.x and how to realize it

Technology