My Drupalcon Barcelona notes

As with previous years, I maintained notes on a publicly available Google Doc during Drupalcon Barcelona. I've tidied them up below for future reference, and added links to the recorded sessions where possible.

NB: these are rough notes made during talks. Please take with a pinch of salt.

---

Monday: community summit

Broadcasting D7->D8 & other info via user groups

Tend to focus on tech rather than community
Better to talk about setting up support structures?
Modules that don't get upgraded: what do I do? Need centralized documentation e.g. tutorial for "how do I replace Nodequeue within D8?"
Any documentation - needs maintaining in a long-term way.
Could the DA manage? Generally want to rely on community and just take leadership.
Plug: tiny.cc/d8bingo
Can we have mappings of: Feature-to-feature. functionality-to-functionality.

BoF on Wednesday.

Other aspects?

* Module maintainer - doesn't plan to upgrade to D8. Thoughts?

* D6->D7 - a lot more sites with D7 than in D8. Could D7 be a Windows XP?

Need non-technical "pamphlets" - business value. Friendly language. 
Why should I care about the security aspect? Don't see security as a return.
Theme layer - D7->D8 - big investment.
Think instead: how long will it take to develop new features.
Could be six months of work? Who will pay?

Hard sell to upgrade every couple of years - especially at low end, especially in non-commercial sectors

What does this pertain to communities?

"How to convince your boss you need to..." kind of pamphlets.
Case studies
Wording

Could be phases: inform people there's a new version, that versions are a thing.
Then sooner or later, start to inform about functionality.
Multi-step information campaign.
There will be a period of time in which D7 will be perfectly acceptable.
Different audiences, though: how do we tackle tech questioners and non-tech questions.

Need to know benefits at the bottom line. Cost, cost, cost.
Could take time to e.g. get new funding etc.

Emphasis on migration? A facility that allows me to get *into* Drupal.
Argument: what has changed since that year? Responsive design, new technologies, sharing.
Developers of course need more resources to explain all of this.

Google - responsiveness and security surveys.
Developer pool.

Offer an upgrade during the build phase?

How to say "yes, you have to rebuild from scratch?"
Could you talk about technical debt per month over D6->D8 cycle. We need a pitch, but we need guidance.

Drupal Uncoded

jam + Kristof
Event for sitebuilders: not frontend, not backend. Just sitebuilders.
Aware mixed profile
But with CMI - could involve completely non-technical people

No service for this community. Sitebuilder track mostly "look at my module".
Opportunity for Drupal to be a prototyping tool. Click crazy stuff together.

"Not a single line of code at this event"? No customization, no Drush (you can use it, but it doesn't alienate.)
Would show the maturity and strength of Drupal.

A really big advantage of Drupal: underestimated. The amount that can be done.
If even D6 was prototypable, D8 should be really strong.
Imagine CUSTOMERS will go to such an event.
Then they might make better decisions.

How do we get it started?
Start identifying sites people want. The click way.
Very different in D8 from any other CMS, where you'd have to either code it or take it the way it comes.
"Architect" role: point-and-click, but eventually, eventually turning to code if they have to.
Site building: should stand on its own, and not be treated as a gateway to allegedly better regarded positions.

Is this niche? Could be much higher in D8?
We say this is a no-code event as a marketing trick, but we obviously want coder-sitebuilders to come along.
A non-coder really wants is: how do I get to this functionality, without code. Satisfying what I want to do.

If you put a developer on a sitebuilding job, there WILL be custom code.

Anyone interested in working on this?
Proposal put together with jam
Put word out to FEU audience / Site Builder audience somehow. Try to get critical mass.
Contact FEU organizers and ask them if they've any thoughts

Tuesday

Driesnote

Needing to talk: big questions.
D8, competitiveness, momentum, usability, client-side apps

* Momentum loss: yes; people are waiiting for D8. Known phenomenon (Osborne).
Expect it could really pick up.
Start building sites on D8 today. For certain type of project, go!

* Why can't we release on time?
RC on Wed 7 Oct!
But: Drupal is 15 years old. D8 has taken 5 of those years
Heroic effort is evidence of a failed process
Realistic planning of build times: The Planning Fallacy.
1. Release depends on all features being complete: so let's start using feature branches, and only merge into master when shippable. Can still use patch workflow, but on feature branch.
What about merges? They're ALREADY painful!
2. Cross-functional teams worked best
3. Orchestrate merges to minimize impact

* Can we compete

In top 10k, Drupal dominated.
Stop comparing with Wordpress (so much): different audiences. But we *can* learn.

* How do we tackle usability

D7 killer release - 70% UX - it took us 8 years but we did it....
Get user effort as close to zero as possible.
Need user testing along the way [Steve Krug!]
Build, measure, learn, iterate.
Focus on non-coders [is the time ripe for Site Builders United?]

* Frontend frameworks
Client-side apps are here to stay
D8 is ready for decoupled CMS + client-side app: exists a REST contract.
App builds layout, though, so typically have to reinvent e.g. block management on D8 side. So fully decoupled is not always best idea.
Progressive decoupling: CMS sends layout.
[What we've wanted since Varnish with ESIs?]
Need a single API call for everything you need but no cruft: working on this, pushing it.
Graph(i)QL [recorded demo, really good!]
This is only made possible because of things we already did (that lost us momentum) so important to keep in mind.

Symfony for Drupal  developers

Larry Garfield (crell)

Symfony is a decoupled system
Symfony full stack <-> Laravel <-> Drupal 8

Symfony docs are great; but here are gotchas:

Drupal should be for content strategists/admins/editors
Symfony is for developers making bespoke apps
Symfony: no UI [but see CLI below]; config=YAML compiled into a PHP class.
No OG or Panels, but Sonata offers rich bundles.
Sonata project: if you want to change the admin dashboard, you're editing a file.
FOS bundles - Friends Of Symfony - more rich bundles e.g. FOSUserBundle

Developing: CLI, plus a dev toolbar which is vg
Scaffolding as per Drupal Console
Dev/prod toggle, in code - toggling entails a force-rebuild of caches!

Completely OO. No functions.

Unopinionated configuration.
YAML but can support others for almost all.

One template per request, but use twig:extends.
Twig: same (apart from template inheritance)

Extending: you basically do hack core, but where core is app/* , bin/*, or web/* (but not vendor/*)
Go ahead and hack these files!

Convention for a single project: src/AppBundle. Only rebundle if you've good reason.
If you rebundle, put in a separate repository and bring in with composer as a 3rd party dependency.
[Any situation when you would ever rebundle into src/* ?]

Dev workflow:
Write, run in dev mode, clear prod cache (several commands); build deploy snapshot
Snapshots - really important for when code and caches out of sync. Just a tarball will do. "Production artifacts" is how you want to use Symfony. We should do it in Drupal but not used to it.

D8 v Symfony: same kernel, different patterns. But it'll be the same code.

Symfony controller: method need to be named *Action() to be autodetected, or otherwise define controller-as-service.
Symfony renders; Drupal always return a render array. Symfony can return an array for a view listener to pick up, but it has a performance hit.

Paths and routing: edit app/routing.* to say "include this file in the bundle, and prefix it with e.g. /bundleprefix/")
Instead of aliasing, use slugs [!]

Logic in services - a stateless object. No globals, avoid static. (applies to D8 too).
Event listeners - like hooks - are glue code

ORM: Doctrine. That's it. Simple objects.
Very close to database, so e.g. no multi-value (need to set up many-to-many with another entity)
Doctrine event listeners do not work the same way as Symfony event listeners
Primitive file handling [but see code tutorials online to turn files into Doctrine objects]

Diversify your business beyond Drupal

Dania Gerhardt (dania.gerhardt)

2 yrs of Platform, but as sales stalled started providing product that could be self-hosted.
Thus went from startup to web-service company.
Eventually closed platform 2 yrs later

Why diversify "away from what's core"?
Need to ask self what does the company stand for?
Strategy and offering - what's the value proposition? Why do clients want to work with you? What is it about you?

Focus v diversified offering - focus gives people an idea of "what you stand for"
50% who come for technology - need a clear delivery focus.
But what about 50% who don't come for Drupal?

Forms of diversification: service, geographical
Means of div: third-party contracting abroad, then partnering or pursuing leads abroad.
Reasons: revenue growth, risk reduction, extending service range, enabling team to grow, aligning synergies, increasing sales, attractiveness of markets

How do it:
four companies in group: Amazee Metrics does SEO/SEM. Austin TX holding company, Cape Town holding company.

Case: Metrics
Into new services - is a risk; were worried would pull down existing company if had problems.
New company team was physically/emotionally close, but different service means they don't really jump across the divide.
Synergies - opportunities for cross-selling

What do diversification steps have in common?
They don't come from a board meeting: they come from an urge, an emotional decision.

Challenges:
Cost & impacts on bottom line
Complexity: accounting, cross-billing, processes, technical complexity, management & direction
Culture and working remotely: even variations of English speaking between countries. Different meanings of "now" between Switzerland and SA...!

Keep teams together by having cross-legal-entity meetings e.g. all frontenders, across all companies, have a monthly online hangout.

BoF: GraphQL

Sebastian Siemssen (Fuhby)

GETs, but you can switch to POST to get round the URL length limit (caching is still for discussion).
Interface: GraphiQL. 3rd party into Drupal.
Able to render with a chosen display mode.
Return structure matches the query structure, which is why verbosity is the same on both sides.

Query builder: but lots of things are objects when they feel wrong e.g. "nid" is {'value': 5}.

Entity:
{ entity { node(id:1) { } } } can use typed data API. More complex args need to use views.
Entity API is very verbose and this unfortunately feeds through.
At that level, we've been thinking about values rather than fetcher methods.
Layered directly on top of typed data (? like EMW in D7?) API, so we lose opportunity of potential method-call layer.

Views:
{ views { VIEW_NAME { DISPLAY_NAME(condition: value, ...) { ... } } } can use the same schema definition as node(id:1), but also doesn't know node type yet.
Condition matches arguments defined in view

Extending:
EFQs could have another schema alongside {views} and {entity}.
This turns Drupal into a data hub, with minimal backend work to have substantially different frontend.

Introspection: discoverable by interrogating the schema rather than using it to return entities.
But compared to REST's established structure; this is a lot of power: sometimes you don't want to give such flexibility to client apps.
Something to work out yet: how do we layer e.g. not just site-wide per-field access, but per-field-permitted-in-a-QL-query access?
Could we return empty values, or error messages, or just discard?

How to handle query contexts e.g. what language to return, and whether to return some fields in one language and some in another? Some kind of decorators.

Can also handle mixins: "fragment FooFragment on EntityNodeContent { ... }". And name queries, for backend logging and hence debugging.

Next step: to figure out what next steps are (!) and open issues in issue queue.

Wednesday

Keynote: Web Psych and science of persuasion

Nathalie Nahai

3 Systems Brain: model that can get us some interesting structure/insights

1. Primal (risk/gratification) symmetry, food and drink, instinctive engagement, nudges, peak highs and lows, checkout as a pain stimulator, scarcity
[Positive response from a tick: might that end up cultural, like colour associations?]
[Use of sex and innuendo can be problematic]

2. Emotional. Mirroring response, social cues, pain and fail videos, trigger empathy, body language in images, offbeat storytelling voices, images of faces, focus on individual but move on to what visitor should do.

3. Rational. Ability to be rational varies, but urge/choosing doesn't happen here. Rationales permit post-rationalisation: positive reinforcement,  freebies, product demos (unboxing!) Different approaches  need to be accommodated to make same decision. Permit many journeys. Make quiet assumptions and people accept them e.g. pick a default package. Be the trustworthy authority but be careful to be consistent and back it up.

[Colgate ad: "Let's unpick the principle of bullshit" - nice comeback]

Persuasiveness targets all 3 systems.

How do we use this to engage community? Need to be honest, focus on genuine, honest mutual benefit. Have to go from "we need to share and promote values" to "how?"

New users scared by complexity. Ensure e.g. sprints feel safe and comfortable. Rational content is all well and good but need to consider primal instincts, that we belong. We're brimming with good spirit: how do we communicate THAT, not our rational explanations?

Surviving fixed bid quotes

Ashleigh Thevenet

Actual budget generally set outside the web team; poor fit
The danger with RFPs: wanting a detailed estimate to win the bid. Bullet-pointed list of desired features, but how do they interact, what do they include etc?

Itemized budget - but every cell is a big question mark

At this point that's OK, but client wants to see you can meet stated objectives. Numbers are not THAT important at this stage. They skim to the budget, eyeball the totals, then if you've met their budget they go back to rest of proposal.

As project evolves need to revise budget: contract reflects this and always says "time and materials" [so not really feasible for e.g. local government]

Case study: how NOT to manage

Long RFP - bullet points, items, features
Tight budget
Worked out to define clients' needs
Discovery process
Moved some items to later phases to deliver immediate needs within budget
Did tell the client, but...
But at the end they said "where were these extra items in the RFP?"
Expectations weren't managed so the project failed

Solution:
integrate two estimate revisions in project discovery and design phase, as project milestones

How could we do a better job explaining what different decisions to do budget?
Solution:
Transparency. Explain what process is and where money is going.

Kick off meeting
Ask right questions
Review proceess
Discuss milestones, scope definition, determining MVP and budget/estimate updates

Client discovery and UX sketches
Rapid Iterative Design: incorporate feedback, make updates
Sketch approval
IMMEDIATE FEEDBACK. Not "take these away and show them round the company." Revise the next day.

STOP: first estimate revision.
Early Tech Planning aka "tier 1"
One meeting
Sketch review. Open broad tickets and provide rouggh estimates.
Goal: estimate with a +/-40% error band.
Advantages: gives overview in terms of dev hours. Early prioritization before moving into wireframes.

Wireframes and comps
Must have complete and approved wireframes and interaction reqs

STOP: second estimate revision
Final Tech Planning aka "tier 2"
Several meetings depending on size of project
Estimate in existing tickets and add new as needed
Add implementation notes
Goal: estimate with a +/-10% error band.

RESULTS OF THIS ARE DELIVERABLES. Shared with clients, declared up front.

Full feature list with estimates. "Homepage" is an epic; "Build homepage" is a ticket, as is "Theme it".

Prepare budget breakdown in hours and money

Presenting this to a client.
If over, give options: de-scope non-MVP, divide dev between client and vendor teams; can more budget be found?

Clients paying for this? Yep. It's technical planning, with valuable deliverables.
This would happen anyway, but it's spent up front to avoid rabbit holes and rebuilding.

When building:
Keep track of overages and discuss with client
Out-of-scope added as new tickets, estimated, prioritized
Provide weekly budget and status checkins
Demo often

Wrapping: deliver MVP within budget, informed and expectation-managed client; already have a Phase 2 lined up!

When doesn't work:
client provides discovery deliverables. Review theirs and make sure notes are sufficient and clear
Time and materials: go Agile!

Disadvantages:
Requires client buyin
Tech planning difficult to schedule, long and tedious
Trying to improve efficiency

Pain points in contributing

Kalpana Goel (kgoel), Valery Lourie (valthebald)

http://bit.ly/pain-points-notes 
http://bit.ly/pain-points-slides 

What is contribution? Organizing camps & meetups; writing docs; manual testing.
Will mainly talk about code contribution

IRC
Learning about it - hard to find from d.o homepage.
No history in most clients: need bouncer or special client

Subscribing to issue notification emails [what's the pain point here?]

How recognize contribution
Recognize for patch reviewers
Don't recognize documentation review unless you provide very specific feedback: it's the same process, the same time-sink.

Encouraging companies to contribute: marketplace reordered as of yesterday
https://www.drupal.org/news/marketplace-updates-to-highlight-contributin...

Contributors to core - we have a long, long tail

Motivation as a pain point
I really want to learn, but have to have work-life balance

Should use git mirror of Drupal core as route into contributing; don't just automatically tell people they've done it wrong
Dreditor and d.o - infrastructure team has to prioritize, but would be good to get on the shopping list 
Almost all issue work is spec work - getting fruits of one's own time rejected is soul-crushing and a setback
Warning: novice tag is not triaged on an ongoing basis
In some cases not always possible to know from the idea alone if the work is possible: sometimes the implementation is what has repercussions.

Defence in depth

Chris Teitzel, David Strauss, Luke Probasco

Predicting hacks by noticing that big companies are sending people to security consultants to just "get more info"!
Average cost of a data breach: $3.79m per breach
As of end of August: 500+ breaches, 140m+ records exposed

YOU WILL BE HACKED

Small businesses are a BIG target: expected to be less prepared and a low-hanging fruit.

Typical breach:
Almost always involves some human error: reused credentials, confused deputies, procedure shortcuts.
Foot in the door in some place; then use to build bigger breaches as they maintain the foothold. Lack of early detection.
NOT involved:
Brute-force cracking modern hashing/encryption; using pre-announced secret vulnerabilities. No Hollywood.

Frame of mind: think from the start
Balance between ignorance and paranoia. Diminishing returns.

Compliance
Regulation compliance is really the low bar. You should always do that, and then more.
Each country has own privacy laws. In the US even an encrypted breach needs to be notified.
PCI DSS: automatically for e-commerce, even if your client doesn't know yet. Use of an approved cloud provider is not sufficient; ned to ensure using in a compliant manner.
New EU data protection comes in this year: based on EU citizen, not where data storer is based!
Fines for non-compliance could cost millions
Best avoidance: do not persist data; if you must, isolate or encrypt.
Personally identifiable information for DPA:
* Full name
* Address
* [... switched slide really quickly]
Piecing together of identity is VERY rapid with 3 or 4 measures [Mac owners born in February].

"CIA" security triad: confidentiality; integrity, availability. Think of all of them, not just one.
C: credentials, 2fa, DPA
I: never trust user input; chmod -r go-w etc.
A: systems need to be up and running, so you can take advantage of the security layers. Have to be internet-available, can't just have HTTP auth on a public-facing website!

"Hacked"; can mean: defacement; DoS; data breach

Defence in depth: device, application, computer, network, physical, policy
Unhardened SSH: "here's the root password!"
Put password on SSH keys

Knowing when you're vulnerable: US Cert/Cert-EU publishes everything, free to get on; LWN rollup of vulns every day on Linux systems; d.o/security; security-only updates with package managers; Twitter announcements every Wednesday.

Simple steps:
* Keep a backup. Roll own backups? Make sure you segment access e.g. use a S3 key that only creates.
* Use version control
* User passwords: use social (Twitter) and/or enterprise (Shibboleth) login instead
* Use secure passwords: OnePassword, LastPass, KeePassX
* Use 2FA
* Password SSH keys
* Rotate admin passwords

Your site is not alone: often breaches come from an API source an external comms.
If you don't need it, hands off: avoid PCI-DSS! Chargify, PayPal, Stripe, Recurly. Avoid £X00,000 PCI audits.
API keys are already points of attack.
Drupal doesn't do anything with e.g. the password form API field. Doesn't hash or anything.
Sitting in the system variable table!
Encrypting with Drupal salt, in the same database, doesn't help much.

Securing stack:
Hosting: does hosting help? Isolate website from the rest of your business.
OS: secure it. Automate configuration. Invest in ability to quickly update. Manage: iptables, SSH (no root, no passwords), sudoers. Compromise: rootkit detect, package verification. Periodically run.
Server: Addd headders e.g. X-Frame-Options; logrotate; disable server headers; prevent access to directories; deploy a WAF with mod_security.
Database: change default passw3ord; lock down access to required hosts; secure backups.
Data encryption: no native way in Drupal; use encryption modules. Encrypt+Key, Field Encryption, Encrypted Files.
Key management: store and manage on a different server from data. Don't tape your key to the front door.
Drupal security: obvs
TEam security: create policy bottleneck/SSO; enforce 2FA and strong pw

If hacked:
Don't panic: notify authorities; roll back; review; reach out. 
Preventing fingerprintability: lost cause? Too many fingerprinting ways; also they run attacks for e.g. Wordpress anyway.
Worth preventing version fingerprinting e.g. CHANGELOG.txt and .info files

Make content your business

Pamela Barone

Initial questions to ask client:
What is your content plan?
Who are your CMS users going to be?
What process/workflows do you need to go from Word into the system?

Don't have a plan? STOP
Planning to make a plan is not a plan. Can't wait until the site is ready.

1. Evaluate: what is the goal? What content is needed?: Does any exist already? Can we repurpose? For others, make a list.
2. Prioritise: what is most important to goals? Refocus effort accordingly.
3. Map: what will putting this together involve?
4. Measure: how much work required to create content? Always more than they think.

Got a plan? GREAT... Let's review
Check assumptions; identify gaps; ask for examples; flesh out the workflows

From content plan to content model

Content editors are people too: CMS users; workshop; include them where possible. [But asking users what features they want can end up with bad UX: just make sure they have a voice]
Engagement reduces resistance; if there's still resistance, surface it early; could be an underlying dysfunction. Get feedback from resisters

Workflows matter: real workflows more important than hypothetical. Focus on efficiency. Beware of rules preventing bad behaviour: probably won't work out very well (people good at finding workarounds). If you start treating people as untrustworthy then it can skew the atmosphere in the room.

Start creating content early. ADD REAL CONTENT. All test content tests is "it goes where it should go." Doesn't test the content model e.g multi-select v single select.

Bad Case Study:
Migration of >1100 sites into one big site, >20,000 pages of content, years of committee planning, big RFQ, minefield of internal politics
One year later
Ran training at end of project for >100 editors and admins.
People were furious. Frustrated. Angry.
Worst of expectations.

What went wrong:
IA/Content plan done in a vacuum
No validation of design or dev
Information piecemeal
No big picture to the site building
Content only added when dev was "complete"
CMS did not support content model
Rework was massive and expensive
Workarounds to solve problems caused even more problems

What to do differently:
Don't start until you have a plan
Recognise clients' limitations - by surfacing a plan
Foster collab and partnership & try to keep relationship amicable

Hard to do perfectly;  but feasible to avoid disaster

Good CAse Study:
Old CMS to Drupal
~5000 items
Static table-based HTML - no way of mapping
Measurements of time required from plan - was too expensive
... So we just migrated as it was. It worked. Six weeks.

Focus on incremental improvements rather than perfection

final points
No single solution. Patterns will emerge, but hard to predict.
Forget about perfection. Do it mostly right.

Perfecting Drupal IA: Menus, Paths, and Breadcrumbs

Jody Lynn

Paths menus breadcrumbs
Drupal should do this out of the box: is that right?

Menu is a tree: avoid having more than one tree; and one page should have one position
This works well for static sites
Menu tree, versus menu displays: extra displays/cross-sections don't matter too much.

Canonical menu positions: we can have more than one position but one needs to be canonical for breadcrumbs etc. to work.
Recommendations: Menu block, Admin menu, Menu Position [like Menu Trails?]

Menu Hall of Shame
Hand-made menus
Crowded menus
Too many menus

Paths
A path is an address. URLs are important - they're part of your UI, design (though absent from mockups), navigation & self-respect
A path should be RESTful
Hierarchical paths - but children don't update when parents do
Stateless, hackable, unique
Pathauto

Paths hall of shame:
JS-only links
Separate mobile sites
Unhackable paths

Breadcrumbs
Worst of all in Drupal out of box
Breadcrumbs missing completely
Or always says "Home"
Maybe the rest of them were eaten by birds
Best way to deal with them is to not have them
[... missed slide...]

Drupal 8: Breadcrumbs are now path based! (See crell talk)

Thursday

Keynote: Contribution beyond source code in Drupal

David Rozas

FLOSS - numerically - has won
But not only about software: e.g. cathedral vs bazaar

Commons-Based Peer Production (Benkler, 2006)
Scholars see this as a new model of socio-economic production

FLOSS is a public goods: non-excluding, non-rival. In fact, it's anti-rival
Drupal as CBPP: collab proc; peer-based, not cooercion; commons-process; favouring replicability

What does contribution mean? Have to understand that to study it
Blurry idea: economy of contribution rather than reciprocity

Code-centrism: what about other contribs?
Affective labour: "working on" social interactions

Finding 1:
Diverse idea of contributions: "... organize talks, meetups, hang out..."
2 types: object-oriented (directed towards deliverables); community-oriented (directed towards maintaining community)
First type is much less visible e.g. in d.o/contribute - all oo represented, no co.
Finding: we need to widen our official-led ideas of contrib to match our rhetoric.

Finding 2:
Profiles: again, show inequality of visibility. Now some Drupalistas overcome fields like bio to overcome limitations
Documentation edits, code commits, number of translations.
You can check you helped organize Drupalcon. No reference of Drupalcamps, local events etc.
Mentors is new. After study, became more relevant, with pictures rather than names.

Finding 3:
Affective labour is surely important - "stay for the community"
"... you realise ther are people behind the source code... becomes something yours"
Friendships develop more strongly doing non-Drupal things
But: as community grows, it gives less of a sense of community; so focus on local communities.
Local activities help to scale up sense of community.

Hacker culture (previous research) make people make decisions/actions probably would nopt have considered otherwise e.g. formally applying to become a developer or not quit

Similar dynamics in non-digital commons
"You become a commoner through common-ing"

Need new dimensions of value, and incorporate them in concise, useful and distributed ways

Mental health in open source

Mike Bell

Last year - burnt out, depression
NOT a doctor; can't tell you what to do

Depression turned simple problems into huge tasks
Anxiety attacks affect your daily life and the things you take for granted. Part of survival instinct, so hard to suppress/control.
Impostor syndrome: stood on stage feeling this right now

"Where's my docs?" - no user guide, API, Stack Overflow

Management: medication (some no longer, some ongoing), CBT

Tabo v stats: 1 in 4 adults can suffer MH
2.6/100 suffer depression right now
4.7/100 anxiety

Attitudes changing, but:

Personal cost: hard questions. What if I lose my job? Fiancee?
Business cost: lose employee at key time; or more subtle - productivity dips gradually but critically
Lack of income etc. causes a cycle of anxiety/depression

The health in mental health: you can go to a doctor for it, just like a bad shoulder, or flu
Fitness for the brain: spend time away from work; spend varied time

Do people know they can get help from *doctor*? Does your employer offer services?
Does your employer let you know about these things BEFORE it's a problem?
Do you recognize any of this in yourself?

Community is awesome: it can ground and help people.

Mike still has to carry on recovering. Will probably never be 100%.

A big step change that we can discuss this at Drupalcon now.

Drupal 8 usability

Angie Byron, Lewis Nyman, Bojhan Somers

Spent a week in U of Minne usability lab
One-way mirror
WebX live stream
Mobile and desktop

Why test now?
Worth testing assumptions
What we can fix before D8 release
What we can fix afterwards

Methodology
Wanted background with Drupal
Wanted them to use Drupal effectively

Scenarios:
Create content; add a link to a page, to a menu; Create a content type with fieds; edit inline; place an existing block
If people got stuck, we had a helpline

After sessions, identify and categorize problems
Assess how frequent, how critical

What worked well?
Mobile: super-impressed, even in-place editing
WYSIWYG: worked to expectations; had problems pasting from Word but we knew that - recent fix addresses that
Content preview: way better than D7
Menu link autocomplete; can also add links to things that don't exist yet (D5 did this!)
D7 seven theme: revamped, action buttons in right area
Inline form errors - accessible

What worked badly?

Weird terminology
Not just blocks, nodes etc. But also were looking for HTML-style terms: "drop-down" doesn't exist - Drupal calls it "select"
Drupalisms ruin people for making other kinds of website
Fix: near future (8.1) introduction to concepts on installation
Far future (9+) terminology review

Place an existing block on the homepage
Went to the homepage and thought "how do I add something TO YOU?" Contextual links :(
Went to block layout - but new blocks are in the RIGHT SIDEBAR. Tester had to ring the helpline!

This makes sense: on content creation, we put less important stuff in the right sidebar. So when we re-used the pattern, people behaved how we should have expected and ignored it!

Scrolled to the region and thought "how do I add something TO YOU?"
Fixed this now. "Place block". Removed sidebar. List of blocks IN YOUR FACE.

Trying to add a field to the content
Names for fields were not intuitive
User blames own lack of site building knowledge :(

Mental model: front to back. Looking for what they expect, not what Drupal decides is the structure.
Field type listing is confusing. Text text text text text
General:boolean is the first item on the list. IT looks like the most important

Shorthand for "entity reference" = "taxonomy term". But because it's the same underneath, it asks them for what entity to reference again. THEN, when they submit the form, it calls it... entity reference!
Possible fixes include: use a modal with simple descriptive text under each option?

Homepage not distinctive out of the box. "Why has my first piece of content become my homepage?"
Having a RON on the homepage is now RETRO. Let's think about how to make it different.

What next?

Semantic versions means continuous improvement in D8
Big opportunity but only if we improve the process

Lean Startup is an obnoxious, shoulder-patting book but the build/measure/release loop is really useful to think about

How other people improve products: paper prototypes, measurement tools, ship really fast
How we improve products: build elaborate cathedrals into core via gatekeepers and bikeshedding, don't talk to users, ignore forums.
We have a build/build/build loop.

Challenges
Devs often unaware of impact of dev decisions on UX
UX entails heated debates and bikeshedding
We don't revamp major site-building tools from UX perspective
UX team is understaffed

What we should do
Document process for big UX changes
Prototype ideas early and often: paper, HTML, NOT in Drupal
Continuous UX testing of core, in dev
Promote awareness of UX problems
Explore ideas for in-Drupal instrumentation ("Big Brother") to help measuring/learning
Resourcing...?

Experimental modules in core (frozen)
We could make changes every couple of months
Revamp based on real user feedback
Gradually move to the fore

BoF: Freelancers Unite, Briefly!

J-P Stacey (jp.stacey)

I ran this BoF, and need to write it up separately; so notes to follow.

HTTP in PHP

David Wehner (dawehner)

What does HTTP look like?
Header
Breaking down URL into pieces: protocol domain, qs, path diff from Drupal path (no leading slash)
Body

How PHP handles URLs?

The old way (0)
$_GET['key'] - different from HTTP
$_SERVER['REQUEST_URI'] etc.
"Warning: cannot modify header information"
It's a fucking pain. What the fuck is that? FUCK YOU!
Difficult to debug.
Custom code, Global. Ugh.

Using libraries (1)
Zend, Guzzle, oath-server-php, Symfony HttpFoundation
Symfony came out at same time as composer came out, hence its popularity. Drupal, PHPBB, Cantao.
Still looks a bit like the global variables underlying it.
Sending data back to client: much clearer advantage.
Objects are injectable and hence testable.
Middleware onion, with application at the core of maintenance handling, caching & logging

Guzzle & advanced guzzle: reacxt to events, asynchronous, middlewares
guzzle-services

PSR-7 (2)
RequestInterface - objects are immutable (?!) which comes from functional programming and no-state
UriInterface
PSR-7-aware middlewares - Stragility, Slim, Relay