O projeto da API WordPress Core Fields está buscando uma nova liderança

Em 2014, o desenvolvedor líder do Pods, Scott Kingsley Clark, assumiu a função principal do projeto Metadata UI. Em 2015, o projeto Metadata UI renasceu como a API Fields.

A API Fields foi desenvolvida para permitir o cadastro de campos em diferentes telas da área de administração através de uma única API. Novas meta-caixas e campos dentro delas podem ser adicionadas às postagens, enquanto novas seções e campos podem ser adicionados à tela do perfil.

O objetivo da API é integrar-se a todas as várias telas de administração, incluindo postagens, termos, usuários, mídia e comentários e fornecer padronização.

Clark lidera o projeto há três anos e, apesar de ter visto um interesse renovado no ano passado, anunciou no canal Slack do projeto que está deixando o cargo.

É com o coração pesado que devo passar a tocha neste projeto. Depois de centenas de horas do meu tempo, não acredito mais que posso efetuar mudanças no núcleo do WordPress.

A visão da API Fields era muito grande, um empreendimento muito grande para qualquer pessoa. Acredito profundamente que o WordPress precisa de uma API Fields, mas a jornada para onde estamos com a API Fields foi longa e árdua.

A verdade é que eu cansei anos atrás enquanto construía o primeiro e o segundo protótipos. Nem todos concordaram em como arquitetar o código, ele passou por muitas revisões com base no feedback dos principais contribuidores. Eu simplesmente não conseguia ter um número suficiente de pessoas empolgadas com isso, eu não conseguia ter um número suficiente de empresas e pessoas interessadas em apoiá-lo.

Eu preciso deixar outra pessoa ter sua chance, estou arrastando para baixo. Se alguém se apresentar para liderar no futuro, ficarei feliz em ajudar onde puder. Mas não consigo continuar liderando a proposta/projeto da API Fields. Sinto muito, por favor, aceite minhas desculpas e espero que você possa me perdoar por não levar este projeto até a linha de chegada. Eu ainda acredito ser uma parte vital do sucesso futuro do WordPress.

Scott Kingsley Clark

As provações e tribulações de liderar um projeto de código aberto

Na entrevista a seguir, Clark explica por que se sente pessoalmente responsável pela falta de progresso do projeto, por que a API é importante para o futuro do WordPress e reflete sobre o que ele poderia ter feito diferente.

Você está olhando para passar a tocha para alguém em particular?

Não, não tenho certeza de quem teria a motivação e a influência para levar o projeto adiante. É um projeto de grande escala que deve ser abordado com uma visão de longo prazo, mas em incrementos pequenos o suficiente para torná-lo no núcleo do WordPress. É pedir muito de alguém, também não é uma prioridade para as pessoas agora, já que estão distraídas com o lançamento de Gutenberg em um futuro próximo.

Por que a API Fields é uma parte vital do futuro do WordPress?

As pessoas olham para o WordPress hoje e se perguntam como sobreviveram sem a API REST. Bem, pelo menos eu sei que sim! O mesmo pode ser dito sobre a API Fields, embora ainda não esteja lá. Existem muitos casos em que é frustrante criar soluções para o WordPress em todos os diferentes ganchos.

Por consistência, é o oeste selvagem lá fora. Você recebe uma meta box registrada e a preenche com o que quiser. Você precisa do seu próprio CSS para estilizar os campos do formulário e todos têm sua própria ideia de como essa interface deve ser. Você é responsável por seus próprios layouts responsivos que são compatíveis com dispositivos móveis, há tanta coisa que você precisa lidar por conta própria. Você deve ser capaz de personalizar as aparências, mas cada lugar onde você deseja adicionar um campo ou formulário deve realmente ter uma API adequada.

A longo prazo, imagine registrar campos no WordPress como você registra tipos de postagem. Imagine campos e suas configurações disponíveis para a API REST e acessíveis por meio do aplicativo WordPress ou outros aplicativos personalizados.

O mundo inteiro se abre porque você tem uma API consistente, o mundo inteiro faz sentido porque você tem uma interface consistente para esses campos nas várias telas de edição. Postagens, termos, comentários, usuários, mídia e até o Personalizador teriam a mesma API subjacente para adicionar grupos, painéis e campos às suas telas.

Se o Gutenberg fosse feito depois que a API Fields estivesse instalada, a migração para as pessoas não teria sido tão difícil. Gutenberg poderia ter mostrado automaticamente todas as interfaces da API Fields como faz para a compatibilidade com versões anteriores da caixa meta. Teria ficado muito mais bonito também.

Tomando algum tempo para refletir, o que você poderia ter feito diferente para conseguir que mais colaboradores principais aderissem ao projeto e o transformassem em uma prioridade mais alta?

Não tenho certeza, é um equilíbrio delicado entre receber informações e confiar no resultado final. No início, o feedback era sobre como a API era estrangeira para o WordPress, eles perguntaram se poderia ser semelhante em estrutura a outras APIs, como o Customizer.

Descartamos o código e reconstruímos do zero como um fork do Customizer, ele ainda suportava que o Customizer também utilizasse a API Fields. No auge do desenvolvimento, tínhamos todas as áreas da API Fields implementadas.

Os lançamentos principais estavam se movendo muito rápido, houve muitas mudanças de código de lançamento do WordPress para lançamento que tivemos que acompanhar porque criamos essencialmente um projeto que era um patch gigante para o WordPress.

Não havia ganchos suficientes para fazer o que precisávamos fazer, e muitas seções não eram extensíveis devido a decisões de código que se marcavam como 'final', o que significa que você não pode estender uma classe específica para personalizar como ela funciona.

Eu gostaria de estar em todos os grandes WordCamps nos EUA e na Europa, essencialmente fazendo lobby por esse recurso. Reunindo apoiadores e tal, parece política de certa forma. Eu andava nas reuniões de desenvolvimento do Core, tentando trazê-lo à tona. Tentei legitimar o recurso tendo um canal dedicado no Slack oficial do WordPress, postando atualizações em https://make.wordpress.org/core/ e realizando reuniões semanais.

Por fim, priorizei meu tempo de desenvolvimento ao longo do tempo para reunir as tropas. Essa foi a queda, comecei a ficar esgotado rapidamente após as primeiras reescritas, pois tinha muitas outras responsabilidades em outros lugares além da API Fields.

Não é como se as empresas quisessem pagar facilmente para você trabalhar em um projeto como esse indefinidamente, embora tanto o WebDevStudios quanto o 10up tenham me dado tempo para avançar. Não era um cheque em branco, em algum momento eu tive que voltar ao trabalho faturável. A partir de então, tudo era no meu tempo livre e isso era difícil de administrar em tempos de estresse financeiro e venda/compra de casa.

Há demanda por uma API Fields no núcleo, mas não há mãos suficientes para construí-la. Por que você acha que é isso?

Todo mundo está focado em outro lugar. Há muitas áreas do WordPress que precisam da atenção das pessoas. Há coisas como Acessibilidade que merecem muito mais atenção do que recebe. Mas o foco para mim parece estar no Gutenberg e na API REST.

Gutenberg, especialmente, tem sido um enorme sumidouro de tempo para as pessoas que contribuem e as pessoas que implementam. É um recurso muito grande. É definitivamente maior em escala do que a API Fields, é como um aplicativo totalmente novo que vive no WordPress. A integração com ele exigiu muita educação e tentativa/erro. O foco das pessoas está onde precisa estar agora. É lamentável que Gutenberg tenha vindo antes da API Fields em termos de prioridade e nível de interesse.

Que conselho você daria ao próximo líder de projeto da API Fields?

Este é um grande projeto, todos vão querer dizer que deve ser de uma determinada maneira. Você tem que avaliar as opções e apresentar algo pequeno para o núcleo para começar. Construa sobre isso, mas nunca perca de vista o objetivo de longo prazo da integração em todas as telas do WordPress. Até os formulários de comentários front-end podem prosperar com a API Fields.

Por que você se sente pessoalmente responsável pelo projeto não ser uma prioridade central?

Em um ponto, tivemos impulso. Tínhamos pelo menos três a quatro pessoas ativas. Ele desmoronou porque eu fiquei sem tempo. É minha miopia, é minha culpa. Passei centenas de horas desenvolvendo o projeto ao longo de alguns anos. Eu deveria ter me deixado muito mais tempo para organizar o texto da proposta do recurso e manter a chama acesa nos corações de nossos colaboradores.

Considerando o tempo e o esforço que você dedicou ao projeto nos últimos anos, você sente algum alívio ao passar a tocha adiante?

Se a tocha for passada ou apanhada, vou me sentir muito melhor. O principal alívio é que oficialmente não é mais um peso que eu tenho que carregar sozinho. Não há problema em tentar e falhar, mas ainda é triste.

Espero que alguém ou alguma empresa dê um passo adiante e dedique tempo a isso. Eles poderiam até reacender o fogo em meu próprio coração que se apagou. Por enquanto, eu tenho um item menos importante para fazer. Eu ainda tenho um prato pesado, mas não é mais um fardo tão pesado.

Embora o futuro imediato do projeto não seja claro, os interessados ​​em assumi-lo são incentivados a ler as postagens marcadas com a tag Fields API no Make.WordPress.Core para saber mais sobre sua história. Você também pode conferir a página do Github do projeto.

Se você estiver interessado em assumir o projeto, entre em contato com Clark no Twitter, Slack ou pelo site dele.