Proposed Sessions

D8 Lessons Learned and How We Can Make D9 Better

svettes — Fri, 15 Feb 2013 15:27:20 +0000

Click here to watch D8 Lessons Learned and How We Can Make D9 Better.

After a year of "project managing" Drupal 8, I've learned a lot with some fellow PM's who support me on a weekly basis - Ashleigh & Shyamala. I've also started having retrospectives with the team, so it's great to get their direct feedback and share common trends on these projects.

This proposal is essentially a post-mortem for core development from a non-technical perspective. I'd like to share with you my experiences, both good and bad, and ways I think we could do better.

Some basic problems we'll cover are:

- Community disinterest in project management, difficulties we face in planning and organization ("I don't have time", "I don't know where to begin" etc)
- Problems around managing volunteer projects (unreliable deadlines, plannings that aren't, resource issues)
- Problems around managing core projects (lack of visibility into issues, unpredictability and sheer size of the beast)

I also have a vision of how I'd like to see Drupal 9 core development change, and resources are a big part of that. We have a ladder of expertise to climb in order to build and foster adoption of our Drupal releases, and we're missing key rungs.

I hope to share with you my ideas about:

- What we are doing now to solve the build & upgrade issue (how to get people to build & use the next version)
- How we coule organize teams to maximize support for core development
- What we need to build those teams

I think it's an ideal time to brainstorm with people in the room as well during Q&A to make the most of the time as a group.

Schedule info

Status:

Accepted

Time slot:

Wednesday, May 22 - 03:45pm-04:45pm

Room:

A 105 - Pantheon

Session Info

Speaker(s):

svettes

Track:

Core Conversations

Experience level:

Advanced

Blocks & Layouts Initiative Update

EclipseGc — Fri, 15 Feb 2013 18:27:08 +0000

Blocks & Layouts Initiative has gotten a number of major features into core at this point. Come take a tour of the new features, see how these things are going to work together, and examples of tools that can be built using them.

Get an overview of:

Plugins in Core
Contextual Plugins
Block Plugins
Condition Plugins
Entity Wizards and more.

Plugins in Core

The plugin system was added as part of the foundations of "Blocks and Layouts" and has broader implications for the rest of Drupal. A lot of subsystems within Drupal are leveraging it at this point and it's worthy of a short introduction.

Contextual Plugins

Contextual plugins really amp up the power of the plugin system and allow existing plugin systems to leverage pre-existing data within a site in order to augment a plugin.

Block Plugins

The block system has gotten a significant overhaul in D8 providing block plugins instead of a series of disconnected hooks. This will be a big focal point of the discussion and we will discuss what block plugins look like now, what block plugins currently exist and where this will likely end up before release.

Condition Plugins

Assuming we get this committed, we'll spend some time discussing condition plugins and how they and block plugins work together, how they an be leveraged separately from block plugins and hopefully some examples of them being used elsewhere.

Entity Wizards

Drupal has never had a really easy to use multistep form wizard and the Entity Wizard answers that problem in a big way. Leveraging entity form controllers and tempstore, the wizard provides a very simple mechanic for scripting form controllers together to create a new entity, or perform tasks that could updated an entity with new data.

All in all there is much to discuss and learn. If we have extra time there will be a Q&A session about where we are, and what goals of the initiative were met for the Drupal 8 cycle, and which ones will have to be in contrib.

Schedule info

Status:

Proposed

Session Info

Speaker(s):

EclipseGc

Track:

Core Conversations

Experience level:

Advanced

UX Roadmap to the Issue Queue Revolution

User Advocate — Mon, 25 Feb 2013 19:43:56 +0000

As a follow up to the proposed session “UX Case: Love and Hate in The Issue Queue Garden” we are proposing a Core Conversation that would lay out a possible roadmap that could revolutionize the impact and effectiveness of the Issue Queue in the community.

Why is this important? As the primary mechanism for driving the evolution of Drupal, the Issue Queue must be an effective communication and participatory tool. The problem, however, is that the Issue Queue is like a cluster of isolated islands of concern that, to the uninitiated, are surrounded by the UX equivalent of shark infested waters.

The consequence of this significant UX obstacle is that many sectors of the community (particularly non-technical members) are, to varying degrees, excluded from the process.

Looking at this as a UX matter, we will present a plan for bridging the many islands that form the Issue Queue. We will suggest specific, actionable improvements that we believe could empower *everyone* who wants to help evolve the Drupal platform.

Schedule info

Status:

Proposed

Session Info

Speaker(s):

User Advocate

tsvenson

Track:

Core Conversations

Experience level:

Advanced

Tooling for Drupal core initiatives

Gábor Hojtsy — Mon, 25 Feb 2013 19:46:47 +0000

Click here to watch Tooling for Drupal core initiatives.

Different Drupal 8 core initiatives used different tools to achieve their goals, some of the most common tools included:

IRC meetings at set times
Google Hangouts
issue tags of different kinds (eg. the sprint tag)
heavily organized sprints
http://drupalofficehours.org/
http://vdc.drupalofficehours.org/
groups.drupal.org
http://drupal8multilingual.org/

We wish we'd have tools as rich as envisioned in http://groups.drupal.org/node/144584 but we mostly needed to turn to our own solutions for what worked for our initiatives. What can we learn from these tools and approaches and what kind of improvements would be ideal on Drupal.org to help teams work better.

This is targeted to be more a discussion than a presentation so do not expect leaning back and reading slides all the way.

Schedule info

Status:

Accepted

Time slot:

Wednesday, May 22 - 02:15pm-03:15pm

Room:

A 105 - Pantheon

Session Info

Speaker(s):

Gábor Hojtsy

Track:

Core Conversations

Experience level:

Advanced

Drupal without barriers -- accessibility is about access and enabling

jessebeach — Wed, 27 Feb 2013 01:21:56 +0000

Click here to watch Drupal without barriers -- accessibility is about access and enabling.

I've always been interested in topics of accessibility, but frankly, I always felt too overwhelmed by technical specifications, over-complicated examples and dogmatic specialists who demand nothing less than development purity.

At the end of 2012, while working on Drupal 8 core issues, faced with the Accessibility Gate, I decided to get over my fear. I installed ChromeVox and for the first time listened to Drupal. After a few days of tinkering with Toolbar I realized that accessibility is fundamentally just holistic interface design and development. We wouldn't build a form without a submit button, but render that submit button as a span tag with a JavaScript submit behavior and it is invisible to a screen reader.

Drupal 7 is quite impressive in its support of accessibility. It is easier to use than Drupal 6 and under the hood, the theme-layer markup is largely semantic and well qualified with ARIA properties. For content-driven, mostly static pages this level of support is adequate.

The direction of the web has been and continues to be towards dynamic pages and single-page applications. Describing the state of the page on delivery is no longer sufficient. We need to update our UIs structurally to represent the state of our pages. I will venture a guess that many of us mentally conflate the representation of application state (the model) with the visual UI (one of the views).

In order to really address accessibility, one of the things we need to do as designers and developers is tease the representation of state out of the visual UI and render it through markup. In this way, both our visual and aural UIs (and perhaps other modalities) will be driven from this common model -- the markup.

We have pieces of this already: an abstract theming layer for markup; a presentation layer for CSS; a JavaScript layer for behavior. Drupal module and theme developers have robust tools to build strong visual UIs. We lack common tools to express page state through non-visual modes.

What we've begun to build in Drupal 8 are the tools to build robust aural UIs. These include using Backbone models to drive visual and aural views and a method 'Drupal.announce' that will read aloud strings passed to it. We're working on a tabbing management utility that will better express salient elements of a page when a user begins a task flow.

My goal is to build a transparent, easy-to-implement and perhaps somewhat automatic aural presentation layer, like the visual presentation layer, that core and contrib can leverage.

To do this, we need to be diligent about separating state from presentation. We need to understand that accessibility is a synonym for universal access. We need to design UIs that express our content and applications through multiple modalities. We need to become comfortable with testing our pages with screen readers.

Most of all, we need to relax and let go of the fear of getting it right on the first try. I want Drupal 8 to have the tools to let contrib experiment so that when the Drupal 9 release cycle spins up, we will build aural and visual UIs along side each other.

In this session, we will spend some time brainstorming what additional tools we might need. Ideas will be recorded and translated into issues.

Slides

A persistent link to the slides for this presentation.

Notes

A persistent link to the notes that will be developed during this conversation.

Schedule info

Status:

Accepted

Time slot:

Tuesday, May 21 - 05:00pm-05:30pm

Room:

A 105 - Pantheon

Session Info

Speaker(s):

jessebeach

Track:

Core Conversations

Experience level:

Advanced

Hard problems (placeholder)

chx — Wed, 27 Feb 2013 01:34:04 +0000

I have no idea yet what the hard problem of the time will be but I am certain we will have some hard problem to hash out <1.5month before feature freeze. I will need a whiteboard.

Schedule info

Status:

Proposed

Session Info

Speaker(s):

chx

Track:

Core Conversations

Experience level:

Intermediate

Speeding up Simpletest

chx — Wed, 27 Feb 2013 01:35:10 +0000

DDL is slow. Let's write something that avoids it. Once SQL strings are largely out of the way can we / do we want to have functional testing with mockup database/entity/config drivers?

Schedule info

Status:

Proposed

Session Info

Speaker(s):

chx

Track:

Core Conversations

Experience level:

Advanced

The end of Hooks

Crell — Mon, 04 Mar 2013 00:58:38 +0000

Drupal 8 will ship with not one but two event systems. One is the Symfony Event Dispatcher. The other is hooks. But really, do we need two event systems? No, we don't.

Hooks have served us well for many years, but I believe it is time to let them go. Hooks are not compatible with unit testing, with dependency injection, with lazy-loading of code, or any of the other techniques and approaches that Drupal 8 and later will be built on. Events are more powerful, cleaner, and have less baggage from the PHP 4 era.

For Drupal 9, let's rip off the band-aid. Let's give hooks an honorable burial and move forward.

It's not a trivial transition, and there are still some questions to sort out. This session will present an argument for moving entirely from hooks to events, lay out the benefits of doing so, and highlight some of the difficulties. Then, as any good conversation, it will invite suggestions on how to address those difficulties.

Schedule info

Status:

Proposed

Session Info

Speaker(s):

Crell

Track:

Core Conversations

Experience level:

Advanced

Rethinking render()

c4rl — Mon, 11 Mar 2013 03:43:47 +0000

### Problem:

Drupal theming in D7 is a hodgepodge of too many APIs. See this helpful diagram for more information (image by John Wilkins).

We outlined how Twig solves a great deal of these issues at BADCamp 2012. But can template variables be smarter? While Twig is well underway to change the syntax of how we write markup, we have much bigger ideas for what it means to render content.

### Goal:

Imagine having template variables that simply would know how to format themselves:

{{ link }}

{{ link.text }}

This would be awesomesauce, no?

### Proposed solution:

This session will summarize and boil down some of the ideas of https://github.com/c4rl/renderapi into an approachable and thought-provoking exploration.
Rethinking render()

Schedule info

Status:

Proposed

Session Info

Speaker(s):

c4rl

Track:

Core Conversations

Experience level:

Advanced

Can Symfony components replace Drupal's venerable Form API?

David Strauss — Mon, 11 Mar 2013 03:45:34 +0000

There are many gaps in the current Form API:

Its design dates back to a pre-OO era of PHP. We use Drupalisms like hash prefixes to distinguish different types of array keys.
Widgets are not very extensible, and we've created widget systems for fields and configuration (admittedly with much code reuse) to make up for the gaps.
The approach to altering creates difficulty for caching.

We could modernize Drupal's Form API, but it's probably better to move to Symfony's form component framework, as provides a promising OO-based, modernized alternative to what we've grown to love.

The presentation will involve an update to the discussion from d.o #1447712, including addressing concerns recently posted.

Useful preliminary viewing: http://drupal.org/files/symfony2-form-vs-drupal-form-api.pdf

I will also try to wrangle in a Symfony developer I know to help answer questions.

Schedule info

Status:

Proposed

Session Info

Speaker(s):

David Strauss

Track:

Core Conversations

Experience level:

Advanced