Processo de Relatório de Status do FreeBSD

Esta tradução pode estar desatualizada. Para ajudar com as traduções, acesse a ferramenta de traduções do FreeBSD.

trademarks

FreeBSD is a registered trademark of the FreeBSD Foundation.

Git and the Git logo are either registered trademarks or trademarks of Software Freedom Conservancy, Inc., corporate home of the Git Project, in the United States and/or other countries.

GitHub is a trademark of GitHub Inc., registered in the United States and other countries.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the “™” or the “®” symbol.


Os relatórios de status do FreeBSD são publicados trimestralmente e fornecem ao público em geral uma visão do que está acontecendo no projeto, muitas vezes complementados por relatórios especiais de reuniões de desenvolvedores. Como eles são uma das nossas formas mais visíveis de comunicação, são muito importantes.

Em todo este documento e em outros lugares relacionados aos relatórios de status do FreeBSD, a expressão "relatório de status" é usada tanto para indicar o documento publicado trimestralmente quanto as entradas individuais que estão nele.

1. Instruções para escritores

Esta seção fornece alguns conselhos sobre como escrever entradas para os relatórios de status do FreeBSD, do David Chisnall, experiente em redação técnica. Instruções sobre como enviar suas entradas também são fornecidas.

Não se preocupe se você não é um falante nativo de inglês. A equipe de status (mailto:status@FreeBSD.org) verificará suas entradas quanto à ortografia e gramática e as corrigirá para você.

1.1. Introduza o seu trabalho

Não assuma que a pessoa que lerá o relatório conhece o seu projeto.

Os relatórios de status possuem uma ampla distribuição. Eles são frequentemente um dos principais itens de notícias no site do FreeBSD e são uma das primeiras coisas que as pessoas vão ler se quiserem saber um pouco sobre o que é o FreeBSD. Considere este exemplo:

O suporte ao abc(4) foi adicionado, incluindo a compatibilidade com o frobnicator.

Alguém que esteja lendo isso, se estiver familiarizado com as páginas do manual UNIX, saberá que abc(4) é algum tipo de dispositivo. Mas por que o leitor deveria se importar? Que tipo de dispositivo é esse? Compare com esta versão:

Foi adicionado um novo driver, abc(4), na árvore, oferecendo suporte às interfaces de rede Frobnicator da linha Yoyodyne.

Agora o leitor sabe que abc é um driver de interface de rede. Mesmo que eles não usem nenhum produto Yoyodyne, você comunicou que o suporte do FreeBSD para dispositivos de rede está melhorando.

1.2. Mostre a importância do seu trabalho

Os relatórios de status não são apenas para informar a todos que coisas foram feitas, eles também precisam explicar por que elas foram feitas.

Continuando com o exemplo anterior. Por que é interessante que agora suportemos os cartões Yoyodyne Frobnicator? Eles são amplamente utilizados? São usados em um dispositivo popular específico? Eles são usados em uma área específica em que o FreeBSD tem (ou gostaria de ter) presença? Eles são os cartões de rede mais rápidos do planeta? Os relatórios de status frequentemente dizem coisas como essas:

Nós importamos o Cyberdyne Systems T800 para a árvore.

E então eles param. Talvez o leitor seja um ávido fã da Cyberdyne e saiba quais novos recursos emocionantes o T800 traz. Isso é improvável. É muito mais provável que eles tenham ouvido vagamente sobre o que você importou (especialmente na árvore de ports: lembre-se de que existem mais de 30.000 outras coisas lá também…​). Liste alguns dos novos recursos ou correções de bugs. Diga-lhes por que é uma boa coisa que tenhamos a nova versão.

1.3. Conte-nos Algo Novo

Não recicle os mesmos itens do relatório de status.

Tenha em mente que os relatórios de status não são apenas relatórios sobre o status do projeto, são relatórios sobre a mudança de status do projeto. Se houver um projeto em andamento, gaste algumas frases apresentando-o, mas depois gaste o restante do relatório falando sobre o novo trabalho. Qual progresso foi feito desde o último relatório? O que ainda falta ser feito? Quando é provável que esteja concluído (ou, se "concluído" não se aplica realmente, quando é provável que esteja pronto para uso mais amplo, para testes, para implementação em produção e assim por diante)?

1.4. Patrocínio

Não se esqueça dos seus patrocinadores.

Se você ou seu projeto receberam patrocínio ou bolsa de estudo de alguém ou você já estava trabalhando como contratado ou funcionário de uma empresa, por favor inclua essa informação. Patrocinadores sempre apreciam quando são agradecidos pelo seu financiamento, mas também é benéfico para eles mostrarem que estão apoiando ativamente o Projeto dessa maneira. Por último, mas não menos importante, isso ajuda o FreeBSD a aprender mais sobre seus importantes consumidores.

1.5. Tarefas Pendentes

Se você precisa de ajuda, deixe isso explícito!

Precisa de ajuda com algo? Existem tarefas que outras pessoas podem fazer? Existem duas maneiras de usar a parte de tarefas pendentes do relatório de status: para solicitar ajuda ou para dar uma visão geral rápida da quantidade de trabalho restante. Se já houver pessoas suficientes trabalhando no projeto, ou se ele estiver em um estado em que adicionar mais pessoas não aceleraria o processo, então é melhor usar a segunda opção. Fale sobre algumas das grandes tarefas em andamento e talvez indique quem está focado em cada uma delas.

Enumere as tarefas, com detalhes suficientes para que as pessoas saibam se são capazes de realizá-las, e convide-as a entrar em contato.

1.6. Envie seu relatório

Os seguintes métodos estão disponíveis para você enviar os seus relatórios:

  • enviar um review no Phabricator e adicionar o grupo status à lista de revisores. Você deve colocar seus relatórios no subdiretório apropriado do doc/website/content/en/status/ (crie-o se ele não existir);

  • enviar uma solicitação de pull request para o repositório doc através do link:https://github.com/freebsd/freebsd-doc [seu espelho GitHub]. Você deve colocar seus relatórios no subdiretório apropriado de doc/website/content/en/status (crie-o se ele não existir);

  • enviar um e-mail para status-submissions@FreeBSD.org incluindo o seu relatório.

Um modelo de relatório em AsciiDoc está disponível aqui.

2. Instruções para editores

Esta seção descreve como funciona o processo de revisão e publicação.

Página principal dos relatórios de status

https://www.FreeBSD.org/status/

Repositório arquivado do GitHub de relatórios de status (foi usado para os relatórios do 4º trimestre de 2017 até o 4º trimestre de 2022):

https://github.com/freebsd/freebsd-quarterly

Endereço de email principal da equipe de status

status@FreeBSD.org

Endereço de e-mail para envio de relatórios

status-submissions@FreeBSD.org

Lista de discussão para receber chamados para os relatórios de status

freebsd-status-calls@FreeBSD.org

Página principal da equipe de status no Phabricator

https://reviews.freebsd.org/project/88/

2.1. Linha do tempo

Os relatórios são sempre aceitos pela equipe de status, mas o principal processo de coleta ocorre no último mês de cada trimestre, ou seja, em março, junho, setembro e dezembro. Chamadas explícitas para relatórios de status serão enviadas nesses meses. Os meses de janeiro, abril, julho e outubro são dedicados a reunir os relatórios enviados durante o trimestre anterior; isso pode incluir aguardar por envios tardios. A publicação dos relatórios de status é feita durante os mesmos meses assim que os relatórios estiverem prontos.

Todas as submissões de relatórios podem ter o prazo estendido enviando um email para a equipe de status até o prazo estendido, que é de 8 dias após o final do trimestre. As entradas da equipe de gerenciamento do ports por padrão utilizam o prazo estendido, devido à sobreposição entre os relatórios de status e os branchs trimestrais do ports.

A revisão dos relatórios enviados por pessoas que não fazem parte da equipe de status deve estar essencialmente concluída até meados de janeiro/abril/julho/outubro (deadline para a revisão de terceiros). Ou seja, exceto por erros de digitação ou outra revisão leve, a equipe de status deve ser capaz de começar a montar os envios logo após o dia 15. Observe que isso não é uma restrição completa e a equipe de status ainda pode aceitar revisões após essa data.

Primeiro trimestreSegundo trimestreTerceiro trimestreQuarto trimestre

Primeira chamada para relatórios

1º de março

1º de junho

1º de setembro

1º de dezembro

Lembrete de 2 semanas restantes

15 de março

15 de junho

15 de setembro

15 de dezembro

Último lembrete

24 de março

24 de junho

24 de setembro

24 de dezembro

Prazo padrão

31 de março

30 de junho

30 de setembro

31 de dezembro

Prazo estendido

8 de abril

8 de julho

8 de outubro

8 de janeiro

Revisão por terceiros

15 de abril

15 de julho

15 de outubro

15 de janeiro

2.2. Chamada para relatórios

As chamadas para relatórios de status são enviadas para os seguintes destinatários:

  • a lista de discussão freebsd-status-calls@FreeBSD.org;

  • a todos os remetentes dos últimos relatórios de status (eles podem ter atualizações ou melhorias adicionais);

  • e, dependendo da época do ano:

    • Diversos organizadores de conferências:

      • AsiaBSDCon em março (primeiro trimestre);

      • BSDCan em maio (Segundo Trimestre);

      • EuroBSDcon entre setembro e outubro (Terceiro-Quarto Trimestre). A EuroBSDcon como organização não está interessada em escrever relatórios para o FreeBSD (pelo menos não estava em outubro de 2019: sua razão é que a conferência não é específica do FreeBSD), portanto, relatórios sobre este evento devem ser solicitados aos membros da comunidade FreeBSD que participaram dele;

    • Para os estudantes do programa Google Summer of Code e seus mentores.

A maneira mais fácil de enviar chamadas para relatórios de status é usar o script Perl sendcalls existente no diretório tools/sendcalls do repositório doc no git. O script envia automaticamente chamadas para todos os destinatários pretendidos. Ele também pode ser usado por meio de uma tarefa agendada no cron, por exemplo:

0      0       1,15,24 3,6,9,12        *       cd ~/doc/tools/sendcalls && git pull && ./sendcalls -s 'Lorenzo Salvadore'

Se você está encarregado de enviar chamadas para relatórios de status e está usando um cronjob, execute-o na freefall e assine-o com seu nome para que seja possível inferir quem configurou a tarefa, caso algo dê errado. Além disso, atualize o exemplo acima com seu nome, como uma medida de segurança adicional.

Pode ser que valha a pena fazer uma chamada para relatórios nos fóruns, como foi feito no passado.

2.3. Construindo o relatório

Os relatórios enviados são revisados e mesclados na subpasta apropriada de doc/website/content/en/status/ assim que são recebidos. Enquanto os relatórios estão sendo atualizados, pessoas fora da equipe de status também podem revisar as entradas individuais e propor correções.

Geralmente, o último passo no processo de revisão de conteúdo é escrever a introdução em um arquivo chamado intro.adoc: uma boa introdução só pode ser escrita depois que todos os relatórios foram coletados. Se possível, é uma boa ideia pedir a diferentes pessoas para escrever a introdução para adicionar variedade: pessoas diferentes trarão diferentes pontos de vista e ajudarão a manter o texto interessante.

Assim que todos os relatórios e a introdução estiverem prontos, o arquivo _index.adoc precisa ser criado: este é o arquivo no qual os relatórios são distribuídos nas várias categorias e classificados.

2.4. Publicação do relatório

Quando todos os arquivos do relatório de status estiverem prontos, é hora de publicá-lo.

Primeiramente, o arquivo doc/website/content/en/status/_index.adoc é editado: a próxima data de entrega é atualizada e um link para o novo relatório é adicionado. A alteração é, então, enviada para o repositório e a equipe de status verifica se tudo está funcionando conforme o esperado.

Em seguida, é adicionada uma entrada de notícias na página principal do site em doc/website/data/en/news/news.toml.

Aqui está um exemplo para uma entrada de notícias:

[[news]]
date = "2021-01-16"
title = "Relatório de Status de Outubro a Dezembro de 2020"
description = "O <a href=\"https://www.FreeBSD.org/status/report-2020-10-2020-12.html\">Relatório de Status de Outubro a Dezembro de 2020</a> está agora disponível com 42 entradas."

Assim que a versão HTML do relatório estiver compilada e online, o w3m(1) é usado fazer o dump do website em formato de texto simples, por exemplo:

% w3m -cols 80 -dump https://www.FreeBSD.org/status/report-2021-01-2021-03/ > /tmp/report-2021-01-2021-03.txt

O w3m(1) possui suporte completo para unicode. O -dump simplesmente produz uma saída de texto da renderização do código HTML, que pode então ter alguns elementos recortados, enquanto o -cols garante que tudo seja enquadrado em 80 colunas.

Um link para o relatório gerado é adicionado entre a introdução e a primeira entrada.

O relatório está finalmente pronto para ser enviado, alterando o posicionamento (o relatório deve ser inserido) e garantindo que ele esteja codificado em UTF-8.

Duas mensagens de e-mail são enviadas, ambas com o assunto no formato Relatório de Status do FreeBSD - <Primeiro/Segundo/Terceiro/Quarto> Trimestre de <ano>:

Este deverá ser aprovado, portanto, se você for responsável por enviar este e-mail, certifique-se de que alguém o faça (envie um e-mail para o postmaster se estiver demorando muito).


Última alteração em: 22 de abril de 2023 por Edson Brandi