El proyecto API de WordPress Core Fields busca un nuevo liderazgo

Traducido del artículo: “WordPress Core Fields API Project is Seeking New Leadership” de:

Jeff Chandler, julio 25 de 2018

En 2014, el desarrollador líder de Pods, Scott Kingsley Clark, asumió el rol principal del proyecto de IU de Metadatos. En 2015, el proyecto de interfaz de usuario de Metadatos renació como Fields API.
La API Fields se habilitó para permitir el registro de campos en diferentes pantallas en el área de administración a través de una única API. Se pueden agregar nuevos cuadros y campos dentro de ellos a las publicaciones, mientras que las secciones y los campos se pueden añadir a la pantalla de perfil.
El objetivo de la API es integrarse con todas las demás pantallas de administración, inclusión de publicaciones, términos, usuarios, medios y comentarios, y brindar estandarización.
Clark ha estado liderando el proyecto durante tres años y, a pesar de su renovado interés del año pasado, anunció en el canal Slack del proyecto que dejará el cargo.
Es con un peso en el corazón que debo pasar la antorcha en este proyecto. Después de cientos de horas de mi tiempo, ya no puedes considerar cambios dentro del núcleo de WordPress.
La visión de Fields API era demasiado grande, una empresa demasiado grande para cualquier persona Creo profundamente que WordPress necesita una API de Fields, pero el recorrido hasta que nos encontramos con la API de Fields ha sido largo y arduo.
La verdad es que me quemé hace años mientras construía el primer y segundo prototipo. No todos estuvieron de acuerdo con la forma de diseñar el código, ni tampoco con las opiniones sobre los comentarios de los colaboradores principales. Simplemente no me puedo entusiasmar, las personas interesadas no podrán ayudarme.
Debo dejar que otra persona tenga su oportunidad, la estoy arrastrando. Si alguien se acerca para liderar en el futuro, entonces me complacería ayudarlo cuando sea posible. Pero no puedo seguir liderando la propuesta / proyecto API Fields. Lo siento, acepta mis disculpas y espero que puedas perdonarme por no llevar este proyecto a la línea de meta. Todavía creo que es una parte tan vital del éxito futuro de WordPress.

Scott Kingsley Clark

Los ensayos y tribulaciones de liderazgo en un proyecto de código abierto

En la siguiente entrevista, Clark explica por qué es el motivo más importante para el futuro de WordPress y reflexiona sobre lo que podría haber hecho de otra manera.

¿Estás buscando pasar la antorcha a alguien en particular?

No, no estoy seguro de quien tenga el impulso y la influencia para ver el proyecto. Es un proyecto a gran escala que debe abordarse con una visión a largo plazo, pero en pequeños incrementos para convertirlo en el núcleo de WordPress. Es mucho pedirle a alguien, tampoco es una prioridad para las personas ahora que Gutenberg está siendo resuelto en un futuro cercano.

¿Por qué Fields API es una parte vital del futuro de WordPress?

Las personas miran WordPress hoy y me pregunto cómo sobrevivieron sin la API REST. Bueno, al menos ¡sé que sí! Lo mismo se puede decir sobre Fields API aunque todavía no esté allí. Hay muchos casos en los que es frustrante crear soluciones para WordPress en todos los diferentes enganches.
Por coherencia, es el salvaje oeste por ahí. Obtienes un meta cuadro registrado y lo llenas con lo que quieras. Necesita su propio CSS para diseñar los campos de formulario y todos tienen su propia idea de cómo debe verse esta interfaz. Usted está a cargo de sus propios diseños, receptores para dispositivos amigables, para dispositivos móviles, hay mucho que debe manejar por su cuenta. Debería poder personalizar las apariencias, pero cada lugar al que se puede agregar un campo o un formulario debería tener una API adecuada.
A largo plazo, imagina los campos de registrador en WordPress como si registrara tipos de publicaciones. Imagine los campos y sus configuraciones disponibles para la API REST y accesible a través de la aplicación WordPress u otras aplicaciones personalizadas.
Todo el mundo se abre porque tienes una API consistente, todo el mundo tiene sentido porque tienes una ventana compatible para esos campos en las distintas pantallas de edición. Las publicaciones, los términos, los comentarios, los usuarios, los medios, incluso el Personalizador, tendrían la misma API para agregar grupos, paneles y campos a sus pantallas.
Si Gutenberg finalizó después de la API Fields, la migración para las personas no había sido tan difícil. Gutenberg podría haber demostrado todas las interfaces de Fields API como lo hace para la respuesta hacia atrás de meta box. Se había visto mucho mejor también

Tomando un tiempo para reflexionar, ¿qué podría haber hecho de manera diferente para obtener más contribuidores principales para comprar en el proyecto y convertirlo en una prioridad más alta?

No estoy seguro, es un equilibrio delicado entre la entrada y la confianza en el resultado final. Al principio, los comentarios sobre cómo la API era extraña para WordPress, preguntaron si podría ser similar en estructura a otras API, como el Personalizador.
Eliminamos el código y lo reconstruimos desde cero como un tenedor del Personalizador, incluso admitimos que el Personalizador también utilizara la API de Campos. En el momento álgido del desarrollo, implementamos todas las áreas de la API Fields.
Las versiones principales se movían bastante rápido, hubo muchos cambios de código desde el lanzamiento de WordPress hasta el lanzamiento que teníamos que seguir porque básicamente habíamos creado un proyecto que era un parche gigante para WordPress.
No había suficientes enlaces para hacer lo que teníamos que hacer, y muchas secciones no eran extensibles debido a las decisiones del código que se marcaban a sí mismas como “finales”, lo que significa que no se puede extender una clase específica para personalizar cómo funciona.
Ojalá pudiera haber sido en todos los grandes WordCamps en los Estados Unidos y Europa, esencialmente cabildeando por esta característica. Reunir partidarios y cosas así, se siente como política en cierto modo. Estuve dando vueltas en las reuniones de desarrollo de Core, tratando de mencionarlo. Traté de legitimar la función al tener un canal dedicado en la cuenta oficial de WordPress Slack, publicar actualizaciones en https://make.wordpress.org/core/ y realizar reuniones semanales.
En última instancia, prioricé mi tiempo para el desarrollo a lo largo del tiempo para reunir las tropas. Esa fue la caída, comencé a quemarme rápidamente después de las primeras reescrituras ya que tenía muchas otras responsabilidades en otros lugares en la parte superior de Fields API.
No es como si las compañías quisieran pagar para trabajar en un proyecto como este indefinidamente, aunque tanto WebDevStudios como 10up me dieron tiempo para impulsarlo. No fue un cheque en blanco, en algún momento tuve que volver al trabajo facturable. A partir de entonces, todo fue en mi tiempo libre y eso fue difícil de manejar en momentos de estrés financiero y compra / venta de vivienda.

Hay demanda de una API Fields en el núcleo pero no suficientes manos para construirla. ¿Por qué crees que es?

Todos están enfocados en otra parte. Hay muchas áreas de WordPress que necesitan la atención de las personas. Hay cosas como Accesibilidad que merecen mucha más atención de la que se consigue. Pero el enfoque para mí parece estar en Gutenberg y REST API.
Gutenberg especialmente ha sido una gran pérdida de tiempo para las personas que contribuyen y las personas que implementan. Es una característica realmente grande. Definitivamente es más grande en escala que Fields API, es como una aplicación completamente nueva que vive en WordPress. La integración con él ha requerido mucha educación y prueba / error. El enfoque de las personas es donde debe estar ahora. Es desafortunado que Gutenberg llegara antes que Fields API en términos de prioridad y nivel de interés.

¿Qué consejo le darías al próximo líder del proyecto Fields API?

Este es un gran proyecto, todos querrán decir que debería ser de cierta manera. Tienes que evaluar las opciones y poner algo de tamaño de mordida para el núcleo para empezar. Aproveche eso, pero nunca pierda de vista el objetivo a largo plazo de la integración en todas las pantallas de WordPress. Incluso los formularios de comentarios del front-end pueden prosperar con Fields API.

¿Por qué te sientes personalmente responsable de que el proyecto no sea una prioridad central?

En un momento, tuvimos impulso. Teníamos al menos tres o cuatro personas activas. Se vino abajo porque me quedé sin tiempo. Es mi falta de visión, es mi culpa. Pasé cientos de horas desarrollando el proyecto en un par de años. Debería haberme dejado mucho más tiempo para organizar el texto de la propuesta de función y mantener los fuegos ardiendo en los corazones de nuestros colaboradores.

Teniendo en cuenta el tiempo y el esfuerzo que ha dedicado al proyecto en los últimos años, ¿siente alguna sensación de alivio al pasar la antorcha?

Si la antorcha se pasa o se levanta, me sentiré mucho mejor. El principal alivio es que oficialmente no es un peso que tengo que llevar solo por más tiempo. Está bien intentar y fracasar, pero aún así es triste.
Espero que alguien o alguna compañía se anime y dedique tiempo a esto. Incluso podían volver a encender el fuego en mi propio corazón que se consumía. Por ahora, tengo un elemento importante menos para hacer. Todavía tengo un plato fuerte, pero ya no es tan pesado.

Si bien el futuro inmediato del proyecto no está claro, le recomiendo a quienes estén interesados ​​en asumirlo que lean las publicaciones marcadas con la etiqueta Fields API en Make.WordPress.Core para conocer su historial. También puede consultar la página Github del proyecto.
Si está interesado en hacerse cargo del proyecto, puede contactar a Clark en Twitter, Slack o a través de su sitio web

 

Quién es Jeff Chandler

Jeff Chandler es un joven de WordPress que forma parte del equipo deportivo estatal. Escritor colaborador de WPTavern. Ha escrito acerca de WordPress desde 2007. Anfitrión del Podcast semanal WordPress.