Come up with an agenda/attendee list for JS sprint at Front End United about drupal-admin-ui HOT 13 CLOSED

🎉

regarding $someone from React/Gutenberg - rendering a thing in React is, ironically, the absolute least of our challenges 😂People doing day-in-day-out client work with CMSes would be more valuable imo

from drupal-admin-ui.

I would like to join.

from drupal-admin-ui.

FYI attendees: Frontend United will be making the sprint free and tickets for the co-working space won't be required 🎉

from drupal-admin-ui.

Could everyone please add their availability to these spreadsheet? We're under "Drupal JavaScript Initiative / Admin UI" https://docs.google.com/spreadsheets/d/1b73QHyqRKzbiL_sdAflnBCGLbLOghhdTq4VjnyQq7_0/edit?ts=5a9f9ba3#gid=0

Thanks!

from drupal-admin-ui.

Also, we planned a social event every night of the week, with limited availability. Please book your spot ASAP: https://www.frontendunited.org/social-track

from drupal-admin-ui.

Wow, that's SO awesome! Thank you, Frontend United! :D

On Monday's call we got clarity around the dates of the sprint, the attendees of the sprint, and their general availability, which is a huge step (updated the summary with that info).

One thing we don't yet have clarity around though is an "agenda" of what we're hoping to accomplish. This is helpful not only for having alignment going into things, but also for people who want to participate remotely to know where they can jump in.

Right now, the proposed agenda is kind of a grab-bag of various things we "could" talk about, from broader roadmap/milestone/alignment stuff, to really digging into the proposed admin UI redesign and how to map that to this initiative, to gnarly architectural things. I would really like to cull that list down, ideally to maybe 3 main things (which would be one for each day + a day for overflow/parking lot), with a shared "deliverable" goal at the end. For example, a more detailed roadmap mapped against proposed milestones + dates that's signed off on by those in attendance, or a working prototype of the react admin UI handling translations + views and using the new UI style, or so on. And let everything we talk about fall under that.

Because otherwise, one of the big concerns I have is that all of those things are important, and all of them are really fucking hard. Meaning I could easily see that we spend a full day and a half of our 4 days talking about just the Views issue, while Cristina with her new admin UI designs twiddles her thumbs in the corner, or whatever.

We have a core committer meeting on Thursday morning (Pacific) which would be an ideal place to share such a proposed agenda, to get outside feedback that the issues we're planning to work on sound like the right ones. That timeline would also give us the opportunity to get a quick announcement out about the sprint, including what days we're planning on talking about what, so that remote folks could make time to attend.

So. Thoughts?

from drupal-admin-ui.

+1 on an agenda. It certainly helps to not go off the rails and do something completely different, even we might not be able to go through all the points.

• I generalized some of the issues (form api / themeable output to describe that it is actually about)

• Replaced challenges with questions. Challenges exist when you know what you want to build, but IMHO that's requires these questions to be answered

• There was not a single emoji in the agenda yet, so I replaced github with github <3 :)

• Added a point on the admin UI design, to define tasks

• (This seems like a VERY lofty list, so we probably want to prioritize it and focus on doing only a few of these things well.)

  From my perspective all depends on these questions. "Build the admin UI using JS to improve the UX" is a really loose definition. Once we have answers to these questions I think things like

• Flesh out roadmap for admin UI: release 1, release 2, release 3... and how/when to integrate upstream with Drupal.

would actually be doable.

• One question which IMHO would be interesting to ask: Are we focusing on the content authors, site builders or both. Are the site builder problems tasks we can actually solve in a reasonable release cycle and solve us some of the problems, so that the content author scope could be smaller afterwards?

from drupal-admin-ui.

One thing which might be worth making clear. As long there are mockups/designs we can continue building. As we go we can add extension points, but I think talking about some of those fundamental questions in parallel is an important step.

from drupal-admin-ui.

Feedback from the core committers:

• Primary goal: Update the roadmap to reflect the current state of the initiative, including priorities/milestones (e.g. this by 8.6, this by 8.7).
• Rather than should we / how can we support translation... e.g. focus on "when" in the roadmap can we be tackling translation?
• Important to define the "scope" of the support of these items. (At this phase, zero views support, at this phase this minimal support, and this phase this expanded support.)
• Dig into architectural problems enough to understand the problem space, what the various parts are, and get at loose estimates of how long it takes. And focus roadmap around parts (Defined not as "20% support" of views, but "this, and this, and this sub-feature.")

from drupal-admin-ui.

I totally understand the need to be able to plan ahead. For me the scope, especially in the full context of Drupal, is just too massive: Hey here build this awesome new skyscraper, but our architect just started and has like 10 other projects to work on first.
Can you give us the cost? :)

An alternative to help estimating projects and actually getting things done is to make the scope smaller. There could be various ways:

• Focus on less than EVERYTHING. For example we could focus for 8.7 to build a nice field UI and reusable form components and in 8.8 to build a nice content add/editing UI using these nice reusable components.
• We don't care about extensiblity: I think initially building a UI without any, but discussing the extension point is one approach. We could say: Our goal for 8.7 is no extensibility and for 8.8 some level, based upon common needs.

Is this some answer to your question?

As far as I understand the point the committers try to make is: Have a plan to stay in focus?

@webchick Would there be a way to potentially get rid of having a proxy for every conversations of this kind? I do understand the need sometimes, but it feels like it is the default. Don't we have the weekly meethings for exactly this?

Primary goal: Update the roadmap to reflect the current state of the initiative, including priorities/milestones (e.g. this by 8.6, this by 8.7).
Didn't we wrote https://www.drupal.org/project/drupal/issues/2926656 not too long ago?

from drupal-admin-ui.

@dawehner we're working with the idea of the content authors as the main ones, but we can go deeper into that in a meeting or in the sprints.

What would be useful for us to be decided at FU:
For the “Eight” theme:

• Will it be used as fallback for React UI?
• Deadlines: when it needs to be done and when it's too late to invest more time on that

For Design:

• Define which components are the most needed for MVP

For UX study:

• Deadlines and milestones to get results for

from drupal-admin-ui.

Maybe the items in the agenda were not sorted yet? That first "Agreement on scope/timeline for initiative w/ Dries + other committers", I would think is the intended outcome of the multiple discussions we need to have.

Edit: nevermind, I see we're still hashing things out.

from drupal-admin-ui.

Similar to what @dawehner says above: it may well be in our advantage to deliberately choose to work inside a well-defined silo instead of a "boiling the ocean" approach.

One analogy I've been thinking of: when "mobile apps" started happening, Adobe didn't try and port the whole of Photoshop into a single iOS/Android app. Instead they identified specific slices of usecases and built apps around that. See the many mini-photoshops on https://www.adobe.com/creativecloud/catalog/mobile.html

Not saying that this would be a desirable end state for Drupal, but it will likely give us clearer path(s) forward towards actual useful results if we start out with choosing smaller boxes to work in.

from drupal-admin-ui.