Provide plain language outline of project scope, direction, and goals #3354
Comments
|
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:
Assuming they will coexist for a long time:
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:
|
|
@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:
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:
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
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:
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. |
|
@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:
|
|
There are comments above with suggestions for what should be here. Mine are at #3354 (comment) 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:
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:
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. |
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. |
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:
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 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. |
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 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: |
|
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: |
|
@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 ***@***.***> 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
<#3354 (comment)>,
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% 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 ***@***.***> 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
<#3354 (comment)>,
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 |
|
Is there any update on the original issue? Specifically this:
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: 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: 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: 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. |
and others
Issue Overview
My observation is the community is struggling to see the wider scope of the Gutenberg project due to lack of a single authoritative plain language resource containing this information. This creates a high degree of speculation, miscommunication, and frustration from all parties and the project suffers as a consequence.
The Gutenberg project needs plain language scope and process documentation: What is the end goal (everything in the view is a block), how are we going to get there (staged releases starting with the editor), and what will that mean for the future of various WordPress components (shortcodes, metaboxes, fields, etc). All (or most of) this information exists as individual comments, pull requests, blog posts, Slack updates, and other satellite information, but to my and the wider community's knowledge there is no single canonical resource where all the pieces are put together in a plain language easy to understand way.
Steps to Reproduce (for bugs)
Expected Behavior
Those familiar with (but not necessarily contributing to) the Gutenberg project should have a clear picture of a) what Gutenberg does now and how it'll impact them immediately, and b) where Gutenberg is headed.
Current Behavior
Possible Solution
The Gutenberg project should publish a comprehensive and plain language central resource outlining the project scope, intended direction, realistic and stretch goals, timelines, sprints, and other information directly tied to the project (ideally the README.md file in the project itself.
Currently this information exists, in parts, in various Make posts, @mtias' post "Gutenberg and the Ship of Thesus", @m's "We Called it Gutenberg for a Reason", in the history of Slack chats, and in pull requests and tickets in this repository.
Due to the fractured nature of this information it is challenging for anyone to get a clear picture of the entire project, and though @mtias and @m's posts do a good job at explaining the grand vision of the project, they lack concrete plain language breakdowns of the essentials the community need to get a firm understanding of what this project is and where it's headed. They also exist as independent satellites of information circling the project rather than core parts of the project itself.
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,
will go a long way in resolving some of the confusion and discomfort felt by all parties involved in these conversations and can serve as a unified resource and reference when questions about issues around metaboxes, locking Gutenberg to the editor, etc arise.
The key to success here is a common understanding of where we are, where we're going, and what the terms we use actually mean. That starts with clear language documentation in one easy to access location.
The text was updated successfully, but these errors were encountered: