Letzte Woche hat sich das Accessibility-Team im Meeting mit den Code-Standards auseinandergesetzt, die für neuen Core-Code im a11y-Bereich gelten sollen. Darüber hinaus hat das neue Marketing-Team die erste Version des „WP Reasons“-Flyers vorgestellt.
Accessibility
Im Meeting wurde beschlossen, die vielen neuen Unterstützer des a11y-Teams in Gruppen mit jeweils einem Lead aufzuteilen, damit sie sich besser zurechtfinden. Dabei wurden die Gruppen Core mit dem Lead Andrea Fercia, Dokumentation mit dem Lead Trisha Salas, Theme-Review mit dem Lead Joe Dolson, Meta mit ebenfalls Joe als Lead sowie das Accessibility-Test-Team mit Rian Rietveld als Lead gegründet.
Näheres zu den einzelnen Teams und den anderen Themen des Meetings findet ihr in der Zusammenfassung von Rian auf Make/Core.
Accessibility-Code-Standards
Während des Community Summit 2015 wurde damit angefangen, Standards für barrierefreien Code zu erstellen. Diese Standards sollen von neuem Code, wie Feature-Plugins, erfüllt werden, wenn sie in den Core integriert werden sollen. Das Ziel ist Release-Code mit WCAG2.0 AA. Diese Standards sollen im Core-Handbuch bei den anderen Standards untergebracht werden.
Die Punkte, die erfüllt werden müssen, betreffen beispielsweise die Semantik des HTML-Codes, Farbkontraste, Nutzung von ARIA-Attributen, die Zugänglichkeit mit der Tastatur und mehr. Genauere Informationen zu jedem der Punkte findet ihr in dem Post von Rian auf Make/Accessibility.
Core
Rückblick auf 4.4
Im Meeting wurde auf den letzten Release zurückgeschaut und vier Fragen an ihn gestellt. Bereits vorher wurde festgehalten, dass die Überschneidung eines Release mit einem großen WordCamp nicht optimal ist – hier sollte mehr Zeit zwischen ein Camp und das veranschlagte Release-Datum gelegt werden.
Konstantin Obenland: What did we do well, that if we don’t discuss we might forget?
[…]
Scott Taylor: did well: we gardened the living daylights out of Trac, at a pretty consistent clip
[…]
Scott: did well: we had 4-5 people committing daily, consistently
Aaron Jorbin: Did well: Got the field guide posts up early
[…]
Aaron: Did Well: Got the email to plugin authors out much much earlier than usual. Was timed with RC1
Konstantin: I think overall we’ve gotten a lot better with sticking to deadlines, 4.4 was a good example for that as well
Scott: did well: there weren’t a lot (or any) big flame wars on tickets - we focused on lots of tickets, instead of getting in the mud on a few
Boone Gorges: Did well: cultivated a culture that encouraged contribs to post regular updates on make/core
[…]
Pascal Birchler: Did well: From my perspective, the whole feature plugin process went very well
Boone: did well: gave lots of first-time props and resolved lots of moribund patches
[…]
Scott: Did Well: New committers all used there commit well and made big contributions. (evident by all of them being renewed)
Helen Hou-Sandí: did well: more willingness to experiment and break things during alpha.
Aaron: DID WELL: #YOLOFRIDAY
Helen: did well (mostly): documented and communicated reasoning and better framing for changes that can be anticipated as controversial.
Tammie Lister:: Did well: got a lot of new contributors for Twenty Sixteen.
Joe McGill: ^ Same for responsive images.
Mel Choyce: Public development of Twenty Sixteen on GH was also great
Joe: GH was key for us as well.
[…]
Konstantin Obenland: What did we learn?
[…]
Helen: that beta and RC are hard to keep up energy for and rely on a lot of institutional knowledge. @mike and i began documenting some of that institutional knowledge during the WCUS contrib day and i believe @drew and @johnbillion are generally working on a release cycle guide doc which would include that.
Boone: That’s worth turning into an action point: would be nice to have better timezone distribution of people with knowledge of/access to w.org deployment tools and processes
[…]
Aaron: I learned that if we decide to change how WordPress is packaged for release, that prep work needs to happen early or releases will be delayed
Boone: Learned: a single contributor/lead with insane dedication can affect release momentum in a huge way. This is good when there is such a person, but is a structural problem if there is not.
[…]
Scott: .com and .org should have a closer relationship as per merges
Boone: Learned: when announcing BC breaks, assume that no one will listen or test unless you shout really loudly
[…]
Aaron: I learned people don’t actually read and when a feature is partially committed, people think it all is committed (RE: API Endpoints)
[…]
Mike Schroder: Learned: We should encourage feature plugin merge decision chats to happen earlier in the cycle, rather than later, with as early an initial commit as possible.
[…]
Konstantin Obenland: What should we do differently next time?
Mel: Work on the About page sooner.
Have any non-English screenshots double checked before committing them
[…]
Aaron:We never discussed feature pointers for 4.4. If they are needed should be a discussion that takes place
Or we should kill all of them forever
[…]
Mika Epstein: Possibly work on the release notes earlier. The wiki page might be easier if it was updated, or even drafted, like we do the weekly notes on core?
Drew Jaynes: We could also improve tooling and start earlier on the version article. That could easily tie to improved tooling for Week in Core (we can double dip).
[…]
Aaron: Release day was fairly stressfull with the go/no go decision not really being clear. I would love to clarify who makes the final go/no go call and how it get’s made.
[…]
Joe: For feature plugins, having a dedicated committer would be helpful. Having @mike was a godsend, but he didn’t have commit during the 4.4 cycle. @azaozz became our MVP down the stretch.
[…]
Sergey Biryukov: Some feedback from a recent Polyglots meeting:
* The hard freeze came in way too late in the day giving teams less than two days (one of which in the weekend) to finalize the 4.4 translations.
* Only translators of the video got mentioned on the release post -– let’s brainstorm ways to mention translation teams in the next release post.
* The new default theme doesn’t support any non-latin characters.
* The screenshots in the About page had content in different languages, but because of the rush some of the content wasn’t done right. Let’s plan for this earlier for 4.5 to make the About page better in terms of l10n.
[…]
Drew: In terms of About page _content_, it would be helpful to define the approval process.
Maybe even collaborate with the newly-minted Marketing team to provide more harmony with the release post and other release promotion assets. cc @sararosso
[…]
Konstantin: What still puzzles us?
Aaron: updating SSL certs
Tammie: font stacks?
Drew: Puzzling: What happened on .org to make it possible to ship Twenty Sixteen unbundled?
[…]
Dominik Schilling: Puzzling: Unit tests and default themes. 🙂
Aaron: Puzzle: Who is going to own getting 4.4.1 out and setting a deadline for it?
Das komplette Meeting könnt ihr im #core-Slack-Channel nachlesen.
Polyglots
Übersetzung des WordPress-Buchs
Es gibt ein Buch über die Geschichte und Entwicklung von WordPress auf GitHub, dessen Inhalt für die aktuelle Version nun fertig ist. Wer interessiert ist, an einer Übersetzung zu arbeiten, soll das direkt auf GitHub tun. Nähere Informationen zur Vorgehensweise gibt es in der Readme des Projekts.
Marketing
Seit Kurzem gibt es ein neues Make-Team „Marketing“, das Marketing-Materialien bereitstellt/bereitstellen wird.
Marketing-/Projekt-Ideen
Auf dem WordCamp Europe 2015 wurden sich Gedanken darüber gemacht, was das Marketing-Team der Community zurückgeben könnte. Dabei sind Ideen entstanden wie ein einseitiger Flyer/ein Datenblatt über WordPress-Funktionen, an dem auf dem WordCamp US bereits gearbeitet wurde. Darüber hinaus könnten die Vorteile von Open Source herausgestellt, ein Vergleich verschiedener CMS erstellt sowie Informations-Banner mit Infografiken erstellt werden.
Nähere Infos zu den verschiedenen Ideen gibt es im Beitrag von Sara Rosso auf Make/Marketing.
„WP Reasons“ – WordPress-Flyer
Auf dem Contributor Day des WordCamps US wurde eine erste Version eines WordPress-Fleyers entworfen, der „WP Reasons“ genannt wird. Dabei handelt es sich um ein Dokument, das Gründe nennt, warum WordPress eingesetzt werden sollte. Im GitHub-Repo gibt es unter anderem das Dokument als InDesign-Datei, als PDF und ein grundlegendes HTML-Dokument.
Und so sieht der Flyer aus:
