Gutenberg: Provide plain language outline of project scope, direction, and goals

This spells out why a clear public product roadmap helps. https://open.buffer.com/transparent-product-roadmap/

Thanks, that would help a lot.

An open question of many site owners planning their direction for the next years should also be covered: the relationship of Gutenberg to page builders.

For example:

• how will they integrate in a first step?
• which areas of page builder functionality will Gutenberg cover in which milestone? E.g. structuring responsive layouts in sections/columns, detailed styling (colors, background images, margins padding and all that stuff). In other words: is the Gutenberg editor seen as a writers tool or also a designers tool?
• WIll Gutenberg support something like a template library?

Assuming they will coexist for a long time:

• Will it be possible to have a block containing a page builder layout?
• Is it a goal to be able to drag a Gutenberg instance or single blocks into a page builder layout?

Not to mention front end editing...

Yes, the Gutenberg Project seems to have a creeping scope that is creating unnecessary FUD about the future of WordPress, especially since the success of the project is overlapping with the success of WordPress itself. While there's lots of efficient, iterative project management, there's a gap with product management that this would address.

This is symptomatic of a larger problem with the WordPress Roadmap that's merely an historical list of releases. The primary barrier for Agencies using WordPress for Client solutions is the RoadMap according to our recent WordPress Usage Survey Report by WordPress Marketing. Despite their high satisfaction with WordPress, some agencies express concern about the lack of awareness of the CMS use case and backwards compatibility.

@Skarjune Based on what I've pieced together from watching the process over the years, reading various published materials from the team, and talking to team members, I don't think there is (much) scope creep here. There is a pretty clear line of reasoning that runs through the whole project and points it in a specific direction going forward. The problem is that information is not contained in one location for people to access. If a single resource was created to outline these things properly I think many people would sleep sounder at night.

A few other things I'd like to see in no particular order:

• The reasoning behind tying Gutenberg to 5.0 specifically vs being a feature plugin ala the REST API work that will be integrated when ready.
• A rationale for taking over the entire edit screen vs the content editor (what this enables, etc).
• A rough timeline for merge, release. What is the team's thinking on when 5.0 should be targeted for release? This could be just a quarter ("Q2 18 vs "Early April") but right now people seem to have varying expectations for when 5.0 would happen and whether it really would wait, say, a year if it took Gutenberg that long to hit the mark.
  
  
  
  • Coincident with that, release criteria. What has to be there before the team would merge? Metabox support and how that's achieved is the current hot button, but the criteria list should go beyond that.
  
  
• What will NOT be in the first release. For example, if support for the Fields API were to be determined as out of scope then it would be in this list. This doesn't need to list everything excluded but should cover larger items that have received external discussion.
• Significant open issues. Again using the Fields API as an example, if the decision to finish that and for Gutenberg to support it was on the table then it would be listed as an open issue so people know it's being debated. Again, this shouldn't be every issue that's open just any large issues that will take significant time or effort or which would have significant impact on the direction and capabilities of Gutenberg.

@mor10 OK, I stand corrected that Gutenberg does not suffer from "scope creep" as a project, but that's the perception of many observers. I've followed the progress since the early Editor Technical Overview post, where I don't see any reference to addressing meta boxes in the UI, only a criticism of shortcodes as a poor implementation for managing data via the editor. My point was merely meant to indicate that some professional users of WordPress are expressing surprise that their constraints are off the table.

I can't speak for everyone using the term, but when I say "scope creep" I am referring to a scope that I surmised based on public statements in Make blog posts, the former landing page of the project (which I can no longer find anywhere), and the current plugin page.

For posterity's sake, this is the current plugin description:

The goal of the block editor is to make adding rich content to WordPress simple and enjoyable.

This is beta software.

The new post and page building experience will make writing rich posts effortless, making it easy to do what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.

WordPress already supports a large amount of “blocks”, but doesn’t surface them very well, nor does it give them much in the way of layout options. By embracing the blocky nature of rich post content, we will surface the blocks that already exist, as well as provide more advanced layout options for each of them. This will allow you to easily compose beautiful posts like this example.

When you read the plugin page, even to this day, there is no mention of meta boxes. We see references to the editor, writing rich posts, shortcodes, custom HTML, embeds, and composing beautiful posts (which then links to an example of post content).

The terminology used in the description of the plugin page would cause anyone familiar with WordPress to expect that the content editor is going to be updated. Why? Because all of those terms mentioned are things we use the content editor for today. There is nothing that would indicate to an unfamiliar WordPress user or developer that the scope of the project intends to go beyond the content editor.

While some may interpret scope based on an internal understanding, I'm looking at it based on these outward-facing materials. The roadmap @mor10 is proposing is an opportunity to get both in sync.

Crosslinking with #3347.

My primary concern is to what extent the data collection changes to accommodate Gutenberg? Does the underlying data structure change our any of it's attendant API endpoints?

I concur with issues raised and discussion on Gutenberg had been highly problematic.

However I would say what needs roadmap at this point is not just Gutenberg, but _WordPress_ itself.

The current project direction of "trendy JS web application platform, based on a legacy core in obsolete PHP dialect, which people actually use to build content sites" is getting bizarre.

At this point selectively quoting from it can seemingly justify:

• absolute backwards compatibility
• breaking backwards compatibility
• major changes in technology
• technology not changing
• learning from larger PHP and/or web development industry
• completely ignoring everything outside of the project

Conversation about Gutenberg is failing not _just_ because its vision is unclear.

It is failing because Gutenberg claims to be vital for _WordPress project_ goals. And in recent years _that_ vision seems to had been steadily losing clarity of purpose, direction, and priorities.

As a minor wordpress editor and lead maintainer of our my organization's wordpress-based site who follows wordpress development mostly from a distance - from occasionally browsing make.wordpress.org and scanning wptavern.com ; I came across this ticket through wptavern and wholeheartedly agree.

I thank @mor10 for putting in the effort to outline the concerns in succinct and clear language, that a clearly page explained page would be very useful. It would provide semi-power users (who aren't in the weeds of and haven't tested this yet, but want a heads-up to see what's coming down the pipeline without directly contacting developers (which can appear as annoying and/or a nuisance) to get an understanding of where wordpress is heading so they can ensure wordpress changes can be implemented on their end.

I agree with @kevinwhoffman. When originally mentioning Gutenberg at our monthly meetups as "the new editing experience for WordPress 5.0" I too expected it to be a replacement for the TinyMCE editor window. I didn't expect it to take over the entire post editor page, based on the outline on the plugin page.

I am getting asked all sorts of questions from worried users about what it means for their site that I can't clearly answer at the moment.

The plugin page mentions that This is beta software but I would contest that this is early Alpha at the very least. It reminds me of early dotcom sites that would post the little "Beta" graphic in the corner of the browser for the following 2 years basically allowing them to get away with not scoping or roadmapping what they were doing allowing the user experience to vary widely.

From Wikipedia

Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs

Gutenberg is nowhere near feature complete in my opinion (just look at the whole iframe saga).

I have had people come up to me the following meetup panicking because when they installed Gutenberg they "lost" a lot of their post data (meta boxes etc). That's not a good position to put people in for beta software.

@rickgregory mentioned in his post about the REST API being a feature plugin for ages until being merged into core. It almost seems as if Gutenberg is following the opposite methodology and being hammered into the next release of WordPress whether users like it/want it or not.

As someone that develops websites for local business, I've found it very difficult understand the scope and vision of the Gutenberg project. I fully supported the need for a better editor but for a long time found the blocks for everything message coming out of the team extremely confusing.

The Gutenberg team understood what a block meant, but as user/developer looking in from the outside, I couldn't grasp it. I stumbled on the "Gutenberg, or the Ship of Theseus" post by accident the other day and it was the first thing I've read that made me understand how blocks might be a good thing. But, I only came across the post by chance.

A definitive document that outlines the vision and scope of the project would go a long way to addressing the concerns of the community at large.

I've been talking to a lot of developers who are frankly scared for their future right now. They don't know if they are going to have to go back and make big changes to all the sites/themes/plugins they have developed in the past. They are afraid to take on big projects right now, in case they have to redo all of their work when 5.0 is released. They don't know when or how they are going to need to train their clients to use Gutenberg. They don't know when or how to teach themselves to develop with Gutenberg. Many of them are afraid that their clients are not going to want to continue using WordPress, and they are considering learning other CMSs or migrating their clients to SquareSpace. It is quite possible that all of these fears are unfounded, but they have no way of knowing one way or the other. A clear outline of Gutenberg's scope, goals, and timeline would help developers plan for their futures, and reassure them that they and their clients can continue to use WordPress.

So everyone thinks its a good idea and would be highly beneficial. The only thing that remains is the question of who is going to write it and when? I would offer to do it but I am not a coder and it really needs at developer at Gutenberg Central to be able to describe and layout all the details correctly. Although I will offer right now to be involved in anything which involves the marketing aspects, which is my strength.

I can report that some months ago a request came in to the WordPress Marketing Team to create a promotional plan for Gutenberg. It was chartered and discussed, but put on hold, as some of us thought it premature as well as being odd to promote a beta plugin to end users without more clarity on it all. For me this brings up a product versus project scope problem, or cart before horse, or some other analogy. Point being: Product needs a road map with an accompanying project scope.

@Skarjune - in a strange way it makes sense that they tried to do that the wrong way round. And somewhat confirms what seems to be the general feeling about the way the project is being run. Be that as it may, whoever writes it, it needs to be written as soon as possible. Too many open questions lead people to go off in their own direction.

I appreciated Morten's presentation about Gutenberg at WordCamp Seattle this past weekend which, to my own surprise, change my attitude about the project as a whole.

He also encouraged everyone to participate in the project which is why I am taking the time to comment here.

Outlining goals and scope is never a bad idea when reassuring people. WordPress often is said to not have an acquisition problem but a retention problem. Managing expectations within the developer community and among the fray (including myself) in the Open Source Bazaar is never a bad thing.

Misunderstandings lead to confusion which leads to burnout.

Thank you for all of your hard work on this project and for all of those who build amazing projects that we all love so much.

Just wanted to drop a note in here to say firstly, thanks for the comments and engagement from everyone. Right now we have a few spread around resources:

Landing/marketing page: http://wordpress.org/gutenberg

Readme: https://github.com/WordPress/gutenberg/blob/master/README.md

Docs: https://wordpress.org/gutenberg/handbook/ (now recently with a better URL).

We can do better though and you are being heard. I wanted to drop in and make sure you knew that.

I have two suggestions, the first is one already being worked on. Currently two of those resources are being iterated on; http://wordpress.org/gutenberg and the project readme. The iterations will include a focus on what Gutenberg is and will be, adding links and resources, taking note of what has been said here and within the community. If possible, just give us a week to get that up as it should at least provide content to iterate on. It's hopefully going to be a good starting point to where we go next in communicating this.

Secondly, I want to hear what you all think would be ideal here. What exactly does everyone want to see produced? What formats work? Would those pages be enough? What for you all would be the format you'd want ideally?

I know it's hard to say whilst those pages are being worked on, but I want to make sure that everything is taken on board to move to the next step. Once those are up, I would love to get more people helping improve our resources and documentation. I will link them here when that happens to start working with those that stepped up to help. Thank you to everyone.

There are two formats that I think would be useful in conjunction:
1) A roadmap showing a list of the features/milestones that will be in place before Gutenberg is released, with at least vague indications of when these things are expected to happen.
2) An FAQ section with answers to questions such as "Will there be metabox support?", "Will I have to rewrite my plugins and themes to be compatible with Gutenberg?" and "Can I revert if Gutenberg breaks my site?" Answers to common questions would really help alleviate anxiety.

As to where these documents live, I think that at least linking to them from the marketing page makes sense. It also makes sense to put the documents wherever they are most likely to be maintained and updated regularly. If putting this stuff on the marketing page is a barrier to updating it, then it should go wherever it is most likely to stay updated, with links on the marketing page.

@wpalchemist Your (1) is the focus of this issue with features and milestones being clarified.
For (2) the project does already have that in GitHub:
https://github.com/WordPress/gutenberg/blob/master/docs/faq.md
@karmatosed showed there are some good resources both there and on WordPress.org, and Yes it'd be nice to have them fully indexed on the main page:
http://wordpress.org/gutenberg

@Skarjune Thank you for the FAQ link! We need to make that easier to find. :)

Good point about the FAQ page, let me make sure that gets into the first iteration of changes I spoke about. Thanks for giving feedback. It does illustrate a lot of this information is there, it's about surfacing it, so a good point taken.

Here are my immediate suggestions:

1. Create a project outline doc complete with current + future goals, timelines, and key decisions including what data structures are kept, what data structures are added, and what designers and developers should prepare for.
2. Create a comprehensive wiki akin to WP-API.org with comprehensive documentation providing current documents and empty/contributors needed documents to make it clear to everyone what exists and what needs to be built.
3. Extend the FAQ to answer questions for admins, designers, and developers

There are comments above with suggestions for what should be here. Mine are at https://github.com/WordPress/gutenberg/issues/3354#issuecomment-342310592 and in general I think Mor10's comment right above this is on point.

I'd like to see what will be in the first release, second etc. In other words, while the end goal of Gutenberg might be a lot of things, what's the feature list for the first release?

Also, I think it's important to have a list of significant open issues AND closed issues. I say this because some of my concern is functional - how will metaboxes be supported etc - but some is also centered on the fact that so much is undefined and uncertain.

In my opinion Gutenberg is blog focused and it might actually be a nice addition for blogs.

As per the image below which is taken straight from on the Gutenberg site:

Add Title
Write your story

Sites that are not used as Blogs, but as sites for companies, for ecommerce, for listings, for jobs, for knowledge bases, for restaurants, for schools, and the long list goes on and on and on, do not write stories.

Gutenberg therefore is utterly useless for those type of sites and keeping in mind that those are also the typical sites that use meta data, the Dev team behind this monstrosity should in my opinion start seeing the light on this one and keep it as a plugin or if it is folded into Core, then only making it active on the default Post post type.

Building on @Rarst's comment above, I would like to see communications that better explain how the approach taken in the development of Gutenberg squares against the philosophy of WordPress itself.

One of the key tenets of WordPress has been a focus on ensuring backwards compatibility. The discussions around metaboxes, the vague timelines, etc. made me think of various conversations over the years around upping the PHP version required by WordPress. To quote Andrew Nacin in one of those discussions around moving from 5.2 to 5.3: "it's really not in our best interest to "play along" at the expense of our users. Tens of millions of users would be affected — and potentially stranded, or certainly wondering why WordPress is putting them in the middle of all of this — all because reasons. It's completely silly. It's also the kind of move WordPress could make that a hosted or alternative blogging solution would love to see happen." This is but one example of something that people have come to expect and appreciate of WordPress as an ecosystem: WordPress will progress but not at the expense of its users.

There a number of modern development practices that I would love to see happen within WordPress, but I have respected that particular philosophy that has made users secure in the fact that when they can often upgrade to the latest and greatest without fear of breaking their sites.

That said, while I've read core Gutenberg contributors mention that they have the 'long time WordPress user' in mind here, I am not seeing the connection, and would love to hear more about how Gutenberg will do this. I personally am very excited by Gutenberg as an editor replacement, and feel the development team should be lauded for many of their efforts in that space.

However, as I read through the conversations related to replacing the entire post/page edit screen, I am just growing more and more nervous. Numerous well-reasoned requests to take a more methodical approach to the release of Gutenberg have been met with responses like:

• Such approaches are not in keeping with the vision of the project
• It won't be released until it is ready.

These are honestly non-answers because they tell us nothing. First: why does a stepped approach to releasing an editor first and then focus on the rest of the edit screen once developers and users get used to the new look run counter to the vision of the project? It more seems like the fear is that it is running counter to some arbitrary timeline that has been implicitly set around this project. And second: what is the expected ready date? 'Sometime in 2018' as the current FAQ states is not an answer at all. What are the parameters by which 'ready' will be defined? As @mor10's initial comments have stated, we really need specifics here. The lack of a clearly defined timeline with milestones within this project is seriously contributing to a lot of anxiety here. It would be great to see a communication that clearly details how the release of Gutenberg is mindful to the core WordPress tenet of backwards compatibility so as not to endanger the millions of users who currently are using it on their sites--with an understanding that variations on 'trust us' are not really an answer.

First: why does a stepped approach to releasing an editor first and then focus on the rest of the edit screen once developers and users get used to the new look run counter to the vision of the project?

Because there's probably not enough resource to go around to work on such an isolated direction on top of the combined direction. If it turns out later the editor-only direction simply won't work out for the big picture, what are you going to do - re-architect the software (massively costly) and re-train everybody (massively costly)? How many such trial-and-error cycles do you think the user base will be able to endure? That's a failed strategy up front.

The impact here is so massively large, that's why there's little room for anything other than an "all or nothing" strategy.

Because there's probably not enough resource to go around to work on such an isolated direction on top of the combined direction.

Limited resources are precisely the reason why an incremental approach makes sense. Our approach should be to reduce sunk costs by validating progress at predefined checkpoints along the way, beginning with the editor.

Instead we have a small number of capable developers focusing on scattered priorities, while the community is being asked to trust that the overall vision will come together at the end of an uncertain timeline. As a result, each release feels like a list of features rather than progress towards any one milestone.

@lkraav - I think you're misunderstanding the point. There's no 'isolated direction' being proposed but a stepwise refinement.

Right now, the proposal is to have Gutenberg take over the entire edit screen. What's been asked several times is why it can't simply replace the editor portion of the screen in its first release, growing to take over more edit real estate over time. This has a couple of advantages:

1) It gets users used to a block editing experience in a limited but useful manner. At the same time, it reduces the scope of work allowing this first phase to be delivered relatively quickly.
2) It avoids having to figure out the meta box (and other?) issues right now and avoids having to have plugins like ACF also modified for Gutenberg in order for many existing sites to not break.
3) Following on #1, it will get the team real world feedback on UX and how a block editor is received by real end-users. That can help direct future design work before so much has been done.

A next phase could take on, say, the meta box issue and expand the feature set. This could continue until the entire vision is delivered.

Eventually, Gutenberg would replace the entire edit screen but, done right, this approach avoids risks of the all or nothing, do it perfectly or break things badly approach.

Finally, I think we need to look at this across a broader timeline. Five years from now, either approach will likely have delivered a finished, robust Gutenberg experience. Does it really matter if that point comes 2 years from now or 3? When we're talking about a dominant player like WP, I think it does not matter. In fact, some amount of caution is better - WP does not need to scramble to catch up to a market leader since it is the market leader. What would be disastrous is rushing out a solution that breaks sites, compromises the ability of front-line agencies to deliver robust solutions and more, all in the service of a rigid design vision that the team won't consider modifying.

First of all @lkraav, I do appreciate the response and completely appreciate the gargantuan task that the Gutenberg team has taken up. I think that we all are in agreement that the impact is massive.

Where I differ from your conclusion is that this is an "all or nothing" binary. As @rickgregory states, focusing on the editor is not veering off in a different direction, but is a step towards achieving the vision your team has set for yourself. I think this is especially pertinent considering the only tangible benefit to WordPress users identified in the FAQ and other documentation at this time centers solely on the content-editor--not the entire admin screen.

I will say that when I hear "all or nothing", that is a bit of a red flag for me, as very rarely is anything that cut and dry. The assumption that a content-block editor cannot work as a standalone component unless all other aspects of the admin screen are also under the control of a central react instance makes this even more worrisome.

There seems to be this assumption that WordPress is broken and we need to make this change in order to survive. If so, if there is this driving need to completely rework WordPress, why hasn't there been more interest in trying out the plugin? The plugin eco-system has shown us that users who feel WordPress is not addressing a particular need do not hesitate adding plugins to their site. And yet, we stand at 3000 installs as of today. You may say "well it is because people don't want to put a beta plugin into their site"...and you are probably right. But hopefully you can understand why we are anxious about jumping from a beta plugin (with minor production usage at best) immediately into core around something that fundamentally changes WordPress.

The fact that timelines cannot be specified makes this all the more confounding. I appreciate the challenge Gutenberg developers have taken on, and if you tell me that "all" is the only acceptable solution and you will take the time needed to get it right, that's fine. However, 5.0 is already slated as the next release...so either it is ready to be merged or you will be driving towards a deadline that has been artificially set without clear understanding whether you can even make "all" work for "all" WordPress users. Within your project plan, I'm curious when will Gutenberg be stable enough for developers to start reviewing how it would impact their plugins & themes? How much time will be provided to said developers to get ready for Gutenberg? If you can't yet answer these questions, I don't understand how you can plan to merge this into core in the next 12 months.

I will say that when I hear "all or nothing", that is a bit of a red flag for me...

I have nothing to do with setting the direction on Gutenberg, so no need to raise flags on account of anything I write. Just interpreting the world here with the rest of you all, spiced with a couple of decades of software development background. I have real clients and personal businesses humming on WordPress, and the broken Visual HTML editing paradigm had reached its limit with me already a while ago. I see exactly what improvements Gutenberg (or the model, as we know it today) can do for my processes and welcome it with open arms, contributing what I can to core and the Gutenberg process.

For the topic: everybody can talk about "iterative" or "all-inclusive" all they want, including me, but words + wishes are cheap and coming up with enough quality pull requests to prove a direction choice's feasibility is what matters.

I just haven't seen anybody else putting in the needed resource to work on these alternative direction ideas fast enough, so at the end of the day, those providing resources will make the calls one way or another. Understandable, because it's expensive as all hell to participate in great (code level) detail, and at the expertise level needed.

And then we'll just have to see how it turns out and try to influence things with our requirements within a chosen strategic direction scope. Admittedly, I don't track the PR list daily (too large), but Gutenberg team has already publicly claimed they are welcoming all contributions. Any change in direction will happen only if someone puts in the hard work of figuring the tech out, quickly enough. "Years" is probably not a reasonable timeframe to put the pieces together.

That's why I predict (not suggest, nor specifically wish, etc) the "all" direction will continue. Personal hypothesis here is that whatever happens, I'll be able to figure things out for my stuff and the clients I serve, because even the current model looks promising enough. It could certainly be proven wrong.

I just haven't seen anybody else putting in the needed resource to work on these alternative direction ideas fast enough, so at the end of the day, those providing resources will make the calls one way or another. Understandable, because it's expensive as all hell to participate in great (code level) detail, and at the expertise level needed.

That is precisely where this kind of project fails – and this in particular. Inability to understand that the capacity to contribute to a good solution is not – can not – be proportional to the ability to write code. I would, on the other hand, say that the ability to write good code is useless (if not dangerous) when the coder does not have a broad sense of the uses to which his code has to respond.

WordPress is what it is because of its flexibility and extensibility, because it is attractive to developers, who can extend its functionality, and to authors and creators, who do not need high knowledge to shape it in their own way. That's also the reason why WordPress is used in a lot of different ways, not only blogs or story-centric sites.

When devising a new way to create and edit content, it is crucial that everyone who contributes to this project has the notion that they can not overlook this flexibility and extensibility, the use of custom fields, the use of custom post types, and other forms of management and interaction with content in WordPress. It's not secondary, it's the core of its success.

If this new edit experience is not able to incorporate this comprehensive range of uses, then it is not ready to be released and shouldn't be released.

@lkraav --No worries...definitely not suggesting that you are somehow responsible for the 'all or nothing' binary. I was just commenting on that particular conclusion because I have read similar statements in other threads and articles related to Gutenberg. And like you, I welcome Gutenberg as a replacement for the Visual HTML editor--no disagreement there from me :)

I did want to comment on pull requests because this points to an issue that @kevinwhoffman raised in his most recent response on this thread. I can completely understand the frustration that some contributors to this project may feel around the limited number of developer resources. However, I think about the conversations in recent months around adopting a JS framework for WordPress that often split between Vue and React. One of the key reasons behind the support for Vue JS was lower barrier of entry to get started. This project obviously started before that discussion took place, but please understand that React's higher barrier of entry will obviously limit the number of people who can contribute to this project. The team decided on its own to utilize react, which is fine, as they are currently doing the heavy lifting; but the team cannot then complain if the number of contributors to the project are not as high as they might like. I for one work in Vue and Angular daily within an enterprise environment but have never touched React due to its BSD licensing issues. As such, the ramp-up time to get to a point where I can provide a quality pull request in React seems prohibitive based on (what is in my perception) an aggressive timeline.

Just adding here that wordpress.org/gutenberg and the readme now have updates. Work in progress but a step in right direction.

I am not going to assume, because I simply don't know. But has Automattic or anyone else at WordPress com/org ever commissioned market research, or studied the available metrics, to be able to say exactly how WordPress is being used?

What percentage use it to tell stories and publish articles in blog form, and how many use it as a CMS to present their company or sell on their ecommerce store? And how is that growing/shrinking/projected?

I should have thought this might be a useful contribution to this discussion and would help us to see the appropriate nature of Gutenberg, or not, to each modality.

Does anyone know if this is available and can shoot us a link in here?

Thanks Tammy! The wordpress.org/gutenberg and wordpress.org/gutenberg/handbook/ sections are very helpful. But is there a full Roadmap to WordPress version 5, as I heard Matt Mullenweg on WP Tavern podcast this week affirm that Gutenberg will ship as core in that. When I look at wordpress.org/about/roadmap/ all that's given is:

Version: 5.0
Planned: 2018
The month prior to a release new features are frozen and the focus is entirely on ensuring the quality of the release by eliminating bugs and profiling the code for any performance issues.

The crux of this issue is that developers are especially concerned about timelines, support sunsets, and deprecations. As an example Drupal offers clear LTS timelines:
https://www.drupal.org/core/release-cycle-overview

Terrence, I looked into market research this year for a Make WordPress Marketing project. There had been some informal polls of designers, developers, and agencies on WordPress, but nothing formal nor conclusive about usage. Our project focused on an informal survey of Agencies on WordPress Usage, solely for the purpose of developing support materials for Agencies to market WordPress to Clients and for consideration of Enterprise adoption.

While we didn't get much traction—we have only volunteer resources and didn't get exposure like the current "Have you taken the WordPress 2017 Survey yet?" link on WordPress.org—but we did gain some valuable insights. Please have a look:
https://make.wordpress.org/marketing/handbook/resources/surveys/wordpress-usage-survey-2017/

@David Skarjune - thanks, that pretty much confirms what I had imagined.
Most organisations forego this step because it brings them face to face
with the reality, rather than letting them do what they want to do, or what
is worse, what they decided to do based on gut reaction and past
experience. So the question remains. what would be the best way to bring
some reality into this story of the back-to-front Gutenberg project. By
the way, I am not sure if I remember correctly, of if I just dreamt it,
but wasn't Gutenberg one of Matt's babies? If so, I wonder what was the
motivation and how "real" that was?

On Fri, 1 Dec 2017 at 16:54 David Skarjune notifications@github.com wrote:

Terrence, I looked into market research this year for a Make WordPress
Marketing project. There had been some informal polls of designers,
developers, and agencies on WordPress, but nothing formal nor conclusive
about usage. Our project focused on an informal survey of Agencies on
WordPress Usage, solely for the purpose of developing support materials for
Agencies to market WordPress to Clients and for consideration of Enterprise
adoption.

While we didn't get much traction—we have only volunteer resources and
didn't get exposure like the current "Have you taken the WordPress 2017
Survey yet?" link on WordPress.org—but we did gain some valuable insights.
Please have a look:

https://make.wordpress.org/marketing/handbook/resources/surveys/wordpress-usage-survey-2017/

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/WordPress/gutenberg/issues/3354#issuecomment-348547816,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD0dztdHtoNFHDbK2mNc_yma5n8O1GFpks5s8C8zgaJpZM4QTl13
.

>

https://qloudpress.com/
Kypeside Stables, Nether Kypeside
by Deadwaters, South Lanarkshire ML11 0JL
Phone: +44 (0)141-416-3322

PGP Key ID: 18D7884E29597525
http://keyserver.pgp.com

@Skarjune - interesting information, thanks for the link. My main concern with that survey as a guide to the WP community is the breakdown of how people describe their roles. Developer... 30%. Content creator... 1%. When asked how many sites they manage, 46% said 25 or more. That audience is typical of agencies, not the people who use WP to create and manage content.

This is a great resource with which to understand the perspective of agencies, but it feels to me like we also need to understand the perspective of people who use the solutions we build.

@rickgregory @TerenceMilbourn The Survey was a small self-selected focus group responding to an open call promoted on WP-org, WP Tavern, and social media, to guide WordPress Marketing. It was not intended as a broad WordPress research vehicle, as explained below. Here's the breakdown of respondents (Company=Client):

Agency: 58  69% 
__servicing​ ​WordPress​ ​for​ ​Clients 46 — 55%
__providing​ ​WordPress​ ​to​ ​Clients 12 — 14%
Company: 18  21% 
__using​ ​WordPress​ ​with​ ​Host 14 — 17%
__using​ ​WordPress​ ​with​ ​Agency 4 — 5%
Enterprise: 8  10% 
__Enterprise​ ​WordPress​ ​(network/cloud) 4 — 5%
__Host​ ​providing​ ​WordPress 4 — 5%

Let's not veer off-topic, but let me comment on the need for a WordPress Roadmap that happens to center on the Gutenberg project at this time.

The survey was my idea in response to ideas generated by the startup Marketing team at WCUS 2016 Contributor Day, specifically for the subgroup on Clients and Agencies that I now chair. My interest was to check with agencies about using WordPress before attempting to promote it to more agencies.

While respondents had more positive ratings of Reasons to use WordPress as opposed to Barriers against it—Roadmap (meaning lack thereof) was a primary barrier, which is why I'm posting on this issue thread.

Yes, it'd be nice to have a broad perspective on WordPress usage, but that would require serious resources and sponsorship. Unfortunately, the argument behind Gutenberg seems to be that bloggers need a block-building system going forward, although I've seen no evidence provided for that, nor why it would be a primary factor given the vast user and use case base

Personally, I've worked on enterprise CMS projects for some years on various platforms, and workflow concerns can be complex. As for the editor, it's typically customized to the workflow and varies per user role, and batch processing is also used. I've never seen an either/or question about which editor is best. The best reference on some of this is "Author Experience" by Rick Yagodich. I spoke on the topic at some WordCamps in past years, but frankly no one cared...now, you'd think it mattered.

@Skarjune - OK, I've had time to read and think about the report now, and
it really is an excellent document. I can see a lot of hard work went into
it and it obviously provides some substantial feedback and validation.

My reaction to it would be, say, as a client who'd commissioned the report,
that it is too limited in its scope for what we want now, as it only really
sets out to capture feedback from agencies and the developer community.

In order to try and understand exactly what Gutenberg should be, and how it
should work, I think we need a far more outward looking approach, so that
we begin to understand the end-user market reaction, intentions, and needs,
when it comes to the kind of content they want to create and manage. And
how they want to do that.

Its surprising to me that curiosity, at the very least, hasn't driven
WordPress or Automattic to commission a market research which, at the very
least, is able to give a definitive break down of industry segmentation,
end-user organisation types, use-case breakdown, etc for all its millions
of end-users.

I mean, how can any one decide what to build, if they don't know who they
are building it for?

If we don't understand these fundamentals, we continue to talk to
ourselves, essentially, and forego any substantial real-world input. And
that means we don't understand what's really needed out there, and might
just press on with building something which the developers think is a neat
solution.

But a solution to what? That's the real question.

With the ability to "push" a questionnaire to millions of end-users via the
WordPress dashboard, for example, we could, if we wanted to really
understand what is needed by the people who use this tool on a day-to-day
basis ~ as apposed to the needs within the WordPress ecosystem ~ take a
truly global sampling of opinions and develop some market definition,
segment size and other metrics upon which to build future goals and
planning.

A cleverly thought out questionnaire and methodology could be extremely
useful, as long as the project wasn't allowed to creep too far.

How would we go about doing something like that. Could we do something like
that?

On Fri, 1 Dec 2017 at 20:01 rickgregory notifications@github.com wrote:

@Skarjune https://github.com/skarjune - interesting information, thanks
for the link. My main concern with that survey as a guide to the WP
community is the breakdown of how people describe their roles. Developer...
30%. Content creator... 1%.

It feels to me like we need to understand the perspective not only of
people who build solutions but of those who use the solutions we build.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/WordPress/gutenberg/issues/3354#issuecomment-348600347,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD0dzqdI4q0CIp4ViLLF6duied048AhEks5s8FsugaJpZM4QTl13
.

>

https://qloudpress.com/
Kypeside Stables, Nether Kypeside
by Deadwaters, South Lanarkshire ML11 0JL
Phone: +44 (0)141-416-3322

PGP Key ID: 18D7884E29597525
http://keyserver.pgp.com

@TerenceMilbourn There is Gutenberg usability testing, so that's helpful along with the call for a clearer roadmap. Telemetry has been discussed for WordPress, but that get's complicated, as would massive research. So, as for Gutenberg, the current focus on usability and roadmap will help us determine if it's appropriate to launch in early 2018 for Version 5.

If you have additional thoughts or suggestions, please join the Make WordPress Marketing Slack channel: https://make.wordpress.org/marketing/

Two goals for 2018 are

Gutenberg editing
Gutenberg customization

Is there any update on the original issue? Specifically this:

A single resource explaining
a) why Gutenberg exists (a simplified version of @m's post?),
b) where it's headed (end-goals + grand vision),
c) why the project is currently focussing on the editor, and
d) that the editor focus is the first building block in a larger plan

I've been searching today for a roadmap document and can't find one.

@mor10, this was reviewed during today's Gutenberg bug scrub we'd like to get your feedback on wordpress.org/gutenberg and this repo's README.md to see if they cover your concerns. If not, what items do you feel are missing and where do you feel they belong (wp.org/gutenberg or readme)?

@jeffpaul For a start, there's no roadmap. No-one will provide a clear answer as to what features Gutenberg will have when it's first released, and/or what features will be in later revisions.

Yes, Gutenberg has added good documentation. But, as some have noted there's not a useful development roadmap, as compared to Drupal for example. While there's detailed development tracking, where's the high level road map?

One big concern is long-term support. It's been said that 4.9.x will be patched after 5.x launches, and that's been the case historically:
https://codex.wordpress.org/WordPress_Versions

Given that the Community is being strongly advised to move forward with 5.0, will legacy versions continue to get patched, and for how long?

There's fear that the legacy path could be confusing. The Classic Editor plugin is offered as a partial solution, but that also requires Gutenberg and some additional configurations. The goal of LTS is to ensure a safe path for some years, when full upgrades to new tech aren't warranted or budgeted.

@maddisondesigns @Skarjune lacking a roadmap document that you're calling for, there's at least the listing of upcoming milestones for Gutenberg.

@Skarjune in my experience, which is less than 2 years volunteering with WordPress core, patches have gone back to 3.7.x. I think it's realistic to expect that patching that far back won't likely last forever, but its even more realistic to expect that any decisions about that will occur during open meetings in Slack with updates posted to Make/Core.

@jeffpaul Honestly, that's mostly useless. All That does is basically provide links to the various tagged Gutenberg milestones. Not only does it only include a very small portion of the issues that have actually been tagged with a Milestone, it's way to easy for anyone to simple change the Milestones, should they decide. What's the point of a roadmap if you can simply change all the milestones the day before the project is released, should you feel like it?

There needs to be a proper (plain English) project roadmap, outlining all the functionality that is going to be available in Gutenberg as at WP5.0, along with what functionality is going to be pushed to the following releases (5.1, 5.2 etc...). At the moment, no-one outside of the Gutenberg project has any idea on what functionality they can expect, once this is finally in core, and no-one will provide any answers when asked. All that we're told is that "_Gutenberg will ship with WordPress 5.0, but the release will come out when Gutenberg is ready, not vice versa_".

Who decides when Gutenberg is "ready"? How do they make that decision? Who decides what functionality is released into core? Who decides what functionality goes into the first version and what goes into the following version? It's obvious that no-one outside of the Gutenberg core developers is going to be involved in this decision. It's ridiculous that the project has gone on this long without any scope or roadmap being defined, which also means that there's been little to no discussion with the WP community as to what functionality people actually want to see in this thing.

@jeffpaul Thanks for the info! That's helpful, but more so for the internal development process and interested parties, not so much for external parties that plan for system architecture and support, both short- and long-term.

For example, Drupal version milestones and LTS are very specific:
Drupal development roadmap
Drupal core release cycle: major, minor, and patch releases

Joomla, on the other hand, is waffling a bit on their new 4.0 framework, which doesn't bode well for the project given their past versioning issues:
Joomla! Project Roadmap

So, despite debate quibbles on Gutenberg, and in the spirit of addressing "Provide plain language outline of project scope, direction, and goals," a detailed roadmap and LTS schedule would make a big difference, especially for agency and enterprise camps. Thanks for your help!

There is a lot of info, as well as the mission statement of Gutenberg (Everything is a block), in the project's README.

While I think there's some good ideas in this issue, the issue has become quite overwhelming with many different voices, different questions, and different aims/goals.

A lot of the feedback in this issue has been addressed/continues to be addressed by the Gutenberg team. One of the common threads I see in here is worries around roadmap/compatibility; I think it's important to remember that WordPress 5 plans to ship with Gutenberg but users can still fall back to the "Classic Editor", so we shouldn't be leaving users stranded.

I'm going to close this because I don't think it's an actionable issue. That's not to say anything/everything in here is wrong or that there are no actionable items. In general there are too many to easily consider this issue "closed".

What have you done with WP Tavern !!?? I come to read WP news and whole portal is in service of Gutenberg propaganda. Give me a break.

Yes, I know the answer. You are not associated with them.