Should the YAML form module change its name?

YAML is a super popular and an easy to remember acronym.

What does ist abrivate?

We could keep the namespace as YAML and change the project title to "Yet Another Form Builder", BTW http://yafb.com/ is taken :)

YAFB. You are on d.o. No extra domain is required. You can rename the project name space, too.

"Form Builder" sounds a lot better to me. No need for "yet another" unneeded tool / wheel reinvent.

Formbuilder is available, but "Form Builder" is taken, won't using this name introduce too much confusion? There's already a lot of communication around the fact that YAML Form is the new Webform, why not keep it that way?

Both "superform" and "super_form" appear to be available. YAML Form is pretty super in my opinion, superseding webform.

If it replaces webform I agree that it should be done this way and committed to webform project.

+1 for committing to the Webform namespace if it is decided to replace Webform (and Webform will not be upgraded). If not Webform, leave at Yet Another Form Builder as there is quite a lot of issues already mentioning the YAML namespace.

Right, makes sense if we can't easily preserve the ecosystem. I don't quite understand the Backdrop reference or how it applies here as I'm not in the loop with it, but sounds like it may be another reason to maintain separation.

That means you can take over the webform namespace.

D8 requires a lot of changes and rewrites and it is clear to all developers that the webform code and integrations need to be rewritten. It is also clear that old webform plugins need to be rewritten. That is why quicksketch has left to backdrop. It is a good idea to do development now in the webform namespace and not later as old D7 code is not D8 compatible and will never be. But D9 may not require so much changes. Webform need to be rewritten, you have done it in a "sandbox". Now use the existing ecosystem to push things faster. I'm sure the plugin developers will more likely join and help as it will happen to your new projects.

We do not support backdrop here and it has itself a limited future. Just waiting for the day when it dies with 2 developers who just do not like to learn OO today...

We should not give up the webform namespace everyone knows for such reasons.

Leave it as YAML-Form.

1. It has been a tremendous success story as "YAML-Form".

2. YAML editing is very powerful and I can rebuild and change forms way faster through YAML than through the GUI.

3. Those, who are setting up sites and creating forms are more than able to understand what YAML-Form is and how it is different to Webform. I am no coder but did create forms through Webform in D6 years ago. I had no difficulties to find out that YAML-Form is the best way to go with D8, right now.

Lastly: Thank you very much for the continued development and implementation of user wishes and inputs!

I'm asking again as I see not a single answer here to my comments.

Why the hell are you not using the webform namespace? There is no webform d8 code and the maintainer left to backdrop. We should reuse it.

I can see @hass' somewhat blunt point. Webform on D8 is essentially at a dead end. YAML form looks to be taking over the functionality it provided. Makes sense for it to do so in the Webform namespace.

Having said that, Webform has a lot of "baggage" (dozens of contrib modules extending it, full upgrade path from D6/7 would be required) so using it's namespace needs careful consideration.

Ultimately this decision rests with @jrockowitz as he's essentially the one doing the work.

As said - none if the old addons/plugins can be used under d8 and need to be rewritten. But the developers are for sure more wilingly to do for webform d8 than for yaml forms they never heard about.

Have you asked quicksketch? He decided to leave Drupal for Backdrop... who cares. He will not maintain a D8 version. Again, issues are against rewritten code. Nothing can get mixed. We will find a way for the migration.

+1 to renaming this, for all of the reasons listed in "Cons" -- have we asked @quicksketch about taking the webform namespace?

@stefan.r I've reached out to @quicksketch as well as the active Webform 7.x maintainers @DanChadwick and @Liam Morland and asked them for their thoughts.

Thanks @fenstrat for reaching out.

Reusing / usurping the webform namespace for D8 would require at a minimum the consent of @quicksketch and @jrockowitz. I am unaware of a Drupal policy that allows the hostile takeover of a branch in a non-abandoned project. There is active maintenance and development in the webform 7.x-4.x branch. @Liam Morland has agreed to take over primary maintainership, so his consent would be needed too.

It is certainly possible to filter a combined issue queue, but it is a pain, and it distorts the module statistics. This is why I routinely mark webform D8 issues as "tasks" so that they don't appear as bugs and so that I can more easily ignore them.

I certainly agree that YAMLform has much the same market position as webform. Since the hopes of a D8 port seem to have died with Acquia backing out of doing the port and @fenstrat's project being cancelled, perhaps the best solution is simply to refer Webform users from the project page to the yamlforms project page.

There is also a big need for a migration path. I believe there is a sandbox form D6 to D8. What might be better would be a D7->D8 path because someone can easily upgrate webform D6 to D7 and then move to yamlform.

I would also welcome some community documentation about differences between yaml and web form. This would help people understand whether yamlform will work for them. Perhaps there is such a thing? I would need continuous updating though.

The argumentum ad hominem directed at @quicksketch is distracting, inappropriate and offensive.

I am fine with YAML Form becoming the 8.x branch of Webform and I am fine with it existing in its own project. @quicksketch and @jrockowitz would both need to agree for it to move into Webform. I agree that YAML Form is not a name that would appeal to less technical people; it sounds like some specialized kind of form, rather than the form module most people would want to use.

I note that the "form" namespace has not much in it and what is there is from D6. Perhaps that could be reused.

Thanks @DanChadwick and @Liam Morland for your replies.

I wouldn't call this a hostile take over of the Webform name space, instead it is renaming @jrockowitz's great work in YAML form to reuse the much more friendly (and available) Webform namespace for D8.

Re the Form namespace, there is a thought for the core Contact module to rename and use that space, so I think it's best left alone.

I've asked @quicksketch again if he could chime in here.

Hi guys, sorry somehow I ended up at #2822361: Link to YAML Form project(and other alternitives?) for Drupal 8 on project page instead of this issue and ultimately suggested the same thing. I built up a new pro/con list in that issue that I'll repost here. Several of those points have been mentioned here already:

Pros:

1. YAML Form provides most (and is working on covering all) the functionality of Webform.
2. The "Webform" namespace is (subjectively) better and well-known name.
3. A "port" of Webform, a module with 500,000 installs, would boost the adoption and reduce hesitancy around Drupal 8.
4. An in-development migration path exists to move existing users to YAML Form.
5. Claiming the Webform namespace would also likely increase adoption of the module.

Cons:

1. Renaming the module would take a development effort, and existing users would need to eventually replace the module with the webform-namespaced version.
2. YAML Form is not actually a port of Webform, and is completely API-incompatible.
3. The migration path is not complete, most notably the submissions themselves are not migrated.
4. Although feature-equivalent, the UIs are similar but not really the same. This could cause confusion for users expecting it to be identical.

As for my personal take on this, I would be happy to see Webform have a continued existence in the world of Drupal. If YAML Form were to claim the namespace, then it would provide at least the appearance of continuity. I believe it would also make the Webform developers feel that their work for the last decade didn't reach a dead end.

@jrockowitz has done an incredible amount of work making YAML Form, and if he were up for the renaming, I would be happy to transfer the project node ownership over to him (with the approval of Liam and Dan).

One one-time task would be to close all existing webform 8.x issues. Shouldn't be more than an hour or two, I'd think, unless we can d.o to do it for us. yamlform could then be webform (perhaps) 8.x-2.x.

@Liam Morland and @jrockowtiz would then have to filter the issue searches. I did this extensively. It's not totally terrible, especially if you bookmark a meaningful query.

I don't mind filtering the issues. I support @quicksketch's proposal.

The D7 Webform module may also need a roadmap. For example, the D7 maintainer need to decide if there be 5.x version of Webform for D7.

The maintainers have discussed this and there will probably not be a 7.x-5.x. We will continue with bug fixes and features that can be integrated without disrupting the stability of 7.x-4.x.

That is great @jrockowitz that you are open to it! I know it may seem overwhelming taking on the seeming responsibility of so many sites, but it's often good to keep in mind what we promise under the GPL. Developers are doing this as a service of passing on the freedoms we received by using Drupal. And while we feel responsibility, it's important to know that you owe nothing to users who use your software for free. Rather than be overwhelmed by a large user base, it can be a source of affirmation and incredibly useful tool to make better software for everyone (yourself and your clients included).

this is going to require me to takeover the Webform module's expectations and issue queue.

As far as Drupal 8 expectations, by the lack of a D8 port of Webform, this may have already happened. It's a slower process as users start building D8 sites, but eventually the same issues would be requested from YAML Form as those in Webform. Actually, I've seen that many long-standing requests have been solved in YAML Form, such as flagging submissions and administrative notes on submissions.

We still have a fairly strong team working on the Drupal 7 version of Webform. Considering the separate code bases between YAML Form and Webform, I don't think it would make sense to enforce the same requirement of feature-parity that we attempted in the past (e.g. between 6.x-3.x and 7.x-3.x). Rather, just let the D8 and D7 branch each do their own thing, developing at separate rates, with each feature requested attempted separately in each branch. The development of Webform on D7 has been slowed for the past year or so, and although new features are still occasionally added, that doesn't need to affect the 8.x branch. So basically let the D7 team do their thing, and the D8 team do theirs. With interested parties that have both D7 and D8 sites doing what they can to port features between the two.

yamlform could then be webform (perhaps) 8.x-2.x.

As weird as it might be for YAML Form, the version number that would follow historical patterns would be 8.x-5.x, essentially being "version 5" of Webform. Then people won't think that the Drupal 7 version (3.x and 4.x) are in any way newer than Webform for Drupal 8. But if a 2.x is preferable, that's fine too. It's not uncommon for modules reset back to 1.x in between major versions.

Fantastic to see consensus coming about here.

Addressing @jrockowitz points:

1. I can help by cleaning out the Webform 8.x issue queue and once that is done with moving any YAML form issues across.
2. Moving the module to Webform places no obligations on you or anyone else to build feature X, Y or Z. Just as @quicksketch said, ultimately you *owe* nothing to your users. If someone wants data analysis then they can contribute it. Also, requiring test for all new functionality should help a great deal for maintainability (something Webform 7.x is largely lacking).
3. Integration with other modules, code review and documentation are all things that can happen moving forward.
4. As @DanChadwick stated the Webform D6 to D7 upgrade path is solid. As such migration from Webform D7 should be the focus. Given D7 still has a decent life time ahead of it this doesn't seem like such a pressing issue right this moment.
5. Consensus seems to have formed that Webform 7.x-4.x will be the final D7 branch.

In terms of branches I'd agree with @quicksketch that 8.x-5.x would make sense. Tough so does resetting to 8.x-1.x.

@jrockowitz if you're good with things I'll go ahead and start cleaning out the Webform 8.x issue queue.

I think 8.x-5.x makes sense. The existing D8 branch is 8.x-4.x, so 8.x-2.x doesn't make sense to me. If it's a reset, it's 8.x-1.x, if not, 8.x-5.x.

@jrockowitz,

You are a champion sir!

I have loved YAML forms and your commitment to adding features from day one.

I know this is a scary / huge undertaken but I know you and other community members will step up. I also think if you (we) were to reach out to the larger drupal shops and ask them for support you could get a lot more people involved.

While I am mostly a front-end guy, I can still help with testing patches, feature requests, help with documenation and present at camps about the module etc..

this is the best thing for the community!

KUDOS

One problem with resetting to 8.x-1.x is that there is already a 8.x-4.x branch with a partial port.

Coming late to the party, I'm not convinced of the advantages of using the webform name space.

In fact I think the best thing going for drupal 8+ and the yamlform name space is it is a good example of the use of YAML not to mention the significant differences between webform and yamlform.

It also maintains the clear distinction of the significant change for developers and clients going from webform to yamlform.

I think better to name it Forms as supposed to migrate parts of it into core experimantal module

@jrockowitz Once discussion finalises here I'll create a planning issue to track the steps in the move.

@Liam Morland I'd planned to empty out the Webform 8.x-4.x branch, it's partial port is at a dead end. Hopefully we can get a d.o maintainer to then delete the -dev release node and the branch. As suggested by @jrockowitz 8.x-1.x makes sense as the branch where YAML Form will move to.

@izmeez It seems we have consensus for the move, additionally I think the advantages outweigh the disadvantages.

@andypost My understanding of those issues you added is that the core Contact module may look to use the Form namespace. Core Contact and Contact Storage (contrib) modules take quite different approaches to form building (using Core's entity/field API). Improved/merged versions of those modules could make it into core, potentially as an experimental Form module. I'm not sure YAML Form -> Webform could take this route?

Great to hear that YAML Form could be moving over to webform. +1!

In response to versions -- typically in the modules I've maintained (panels, ctools, etc) we bump the version number if the API changes. A good example is the ctools project, which had an 8.x-2.x branch as part of the VDO initative, but it ended up going nowhere. With the re-write, we released it as 8.x-3.x. (coming from 7.x-1.x).

I'd highly discourage using 8.x-1.x for the branch. While it is a re-write, it is not the first iteration of the webform-like module. Much like Omega is on version 5 (and had... 4 re-writes?), its better to increment the version to help those who aren't as aware, what the most recent version is. I'd also recommend against using 4.x, not only because of the dead-end code, but because 4.x can imply a direct port/upgrade path from Drupal 7. higher versions, like 8.x-5.x would indicate that this is the newest maintained version. And heck, if the D7 maintainers want to backport the features in 5.x, they could make a 7.x-5.x branch if they wanted.
There might be some build issues as well if you go back to 8.x-1.x. (not entirely sure, but sub versions don't deal well with going down in numbers)..

@japerry Thanks, all compelling points for 8.x-5.x.

If the D7 branch needs a new version, what would it be?

Maybe yamlform -> webform-8.x-10.x, leaving room for future divergent D7 branches? Don't see much harm.

I feel like I'm renumbering statements in BASIC circa 1975. :)

10 probably seems a bit over the top doesn't it? 8.x-6.x would allow a future 7.x-5.x branch, and given at this point there seems like there's no plans for 7.x-5.x this should cover things for the future.

Would be great to hear from @andypost or others Re the core Form namespace future.

I agree. We don't need to delete the 8.x-4.x branch; it's harmless to leave it there.

Sounds good to me. It is possible to merge git repositories, so YAML form can be added to the Webform repo without losing its commit history.

what ever happens in the back of drupal. As a non developer. "YAML scares off non developers" is quite true, although if one will work with this super great module, specially the support there is already. YAML indicates that you have to learn about YAML. Thats what I did and it was useful. It helps a lot to be efficient. The word builder is really important too because.
then we have
YAML how it works, what ist the background
Form for what it is
Builder and what it does
sounds logic to me.
even if it would replace any other form module.
it could even be
YAML Form Builder Module

Considering #2827847: Rename YAML Form 8.x-1.x to Webform 8.x-5.x is opened, moving this to RTBC.

I am starting to feel that just going with using 8.x-5.x gives the larger Drupal community a sense of continuity, which is a good thing. Even if there is a 7.x-5.x version of the Webform module, no one is going to expect it to be a backport of the 8.x-5.x code.

+1

A Webform 7.x-5.x is pretty unlikely in any case. We still have 1/3 of all our sites running 7.x-3.x, making another major version in D7 would cause more maintenance headache that I don't think anyone is willing manage.

@quicksketch

We still have 1/3 of all our sites running 7.x-3.x

Actually pretty good if 2/3 are already on 7.x-4.x through transition or migration from D6.

@rockowitz You've done great work on all this.

I would like to thank you and everyone for their help, support and whish you all a Happy new Year.
Would like to meet you sometime somewhere.

PS Migration worked fine with me. from beta29 to webform 8.x-5.0-beta4

Great to see what happens here. @jrockowitz you've done really great job for the YAML form module and the issue queue. Good efficiency and quality is my impression on this module. Thanks for everyone helping on this and looking forward to the great Webform 8.x-5.0.