process-pt-br

From Microformats Wiki
Revision as of 19:51, 4 November 2006 by Token (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Se essa é sua primeira visita, por favor veja a página de introdução.

Então você quer desenvolver um novo microformato?

Por que?

Deve haver um problema a ser resolvido. Sem problemas, sem microformatos.

Uma vez que você encontrou seu 'problema', pergunte-se: 'há um problema mais simples aqui?' Nesse caso, vamos resolver aquele problema primeiro. Queremos tratar com mais simplicidade o primeiro problema e só então aumentar para problemas complexos.

Também, procure na internet. Há chances são que alguém mais tenha encontrado o mesmo problema que você. Se você ainda acredita que tem um problema não resolvido, poste algo em microformats-discuss na lista de discussão ou qualquer outro canal público (ver http://microformats.org/discuss/) Nós queremos envolver todos as partes interessadas na discussão. Inicie uma discussão ANTES de criar qualquer página no wiki. Não estamos usando o wiki como "bloco de anotações" gerais. Se você não pode resumir o problema que está tentando resolver em um curto email, e sente-se como se precisasse de uma longa documentação, você está provavelmente tentando resolver um gigantesco de um problema - veja paragráfo anterior.


Comportamento Atual do Documento

Documento atual do comportamento humano. Lembre-se, estamos pavimentando o caminho da vaca - antes de fazer você tem que encontrar o caminho-da-vaca. Seus exemplos devem ser uma coleção dos sites do mundo e páginas que são publicadas do tipo de informação que gostaria de estruturar com um microformato. Dessas páginas e sites, você deve extrair exemplos de marcação e de temas internamente implicitos e fazer análises.

Essa coleção de exemplos deve ser pública, preferencialmente em uma wiki pois não há forma de fazer tudo isso sozinho (não importa quantos de vocês são). A página reviews-formats é um bom exemplos de pesquisa feita antes da criação de um microformato. Antes de desenvolver hreview, os colaboradores sairam, documentaram práticas atuais ao redor das revisões em web sites, e forneceram algumas análises de temas internamente implicito.

É bastante possível durante este passo que você encontrará mais outra pessoa que tem tratado desse problema discursado. Talvez até mesmo o resolvido. Faça seu melhor para abrir um dialogo com os outros que tem o encontrado o mesmo problema. Nós não queremos construir paredes entre comunidade competitivas - nós queremos pessoas trabalhando juntas para desenvolver uma boa solução que cobrirá a maioria dos casos.

Proponha um Microformato

Atualmente, NÃO!!!

Há outras coisas para tentar antes de desenvolver um microformato. Primeiro, faça-se essas perguntas:

  1. Há um elemento padrão em XHTML que trabalharia?
  2. Há uma combinação de elementos XHTML que trabalhariam?
  3. Ok, se a resposta para as duas acima é 'não,' nós podemos conversas sobre um microformato.

Para mais detalhes em XHTML semântico, exemplos de uso de elementos XHTML, e construção de combinações XHTML, veja The Elements of Meaningful XHTML.

Primeiro você deve observar the microformats principles.

Antes de você entender os principios, pergunte-se: "há alguma bem estabelecida, padrões implementado de interoperabilidade que podemos examinar em que tratam desse problema?" Por exemplo, hCard e hCalendar foram contruídos sobre o topo dos padrões IETF para vCard e iCal, respectivamente, ambos que são largamente implementação de interoperabilidade. Os desenvolvedores desses padrões já tem gasto muitos anos nos comitês de padrões debatendo e desenvolvendo os esquemas. Melhor influenciar todo o trabalho duro que outros fizeram antes de você, do que isolar-se como um caubói, e perder tempo repetindo todos seus enganos.

Também é mais fácil para começar de um esquema bem estabelecido e mapear para XHTML do que desenvolver um esquema novo.

Lembre-se, microformatos devem ser designados para humanos em primeiro lugar e máquinas em segundo. aqui há poucas perguntas que podem ajudar a você se realmente precisa de microformato para o problema que você está tentando resolver:

 Se eu olhar para esse microformato em um navegador que não suporta CSS ou tem CSS desligado, ainda seria humano-legível?
  1. os estilos dos elementos desse formato estão com CSS?

Se o formato proposto não passou nessas duas coisas, não é provável que ganhe muita aceitação. Lembre-se: humanos primeiro, máquinas segundo.

Iterate

Depois de propor um microformato, você obterá muito retorno de outros interessados no microformato. A proposta precisa ser reiterada e adaptada. Desenvolvimento de microformato deve ser colaborativo e baseado em comunidade.

Aqui está uma arte ASCII em fluxograma:

DIAGRAMA:
indicação do problema---->pesquisa/discussão---->proposta/esboço---->padrão
^___________________V   ^__________________V   ^_______________V

Note que cada estágio envolve iteração. A iteração consiste de discussão e retorno e deve resultar em maiores mudanças. Não tenha medo de fazer maiores mudanças e por favor não fique ligado demais a qualquer situação particular.

Páginas para considerar criação

Um padrão emergiu de esforços de desenvolvimento de microformatos bem sucedido de diversos tipos especificos de páginas wiki sendo criada, em ordem particular (embora nem sempre).

Depois de uma área de problema especifico (*) tem sido determinado (princípio1), considerar criando e preenchendo as seguintes páginas para isso. Se você está inapto a produzir material para páginas, então você deve provavelmente reconsiderar se ou não o problema é importante (ou pronto para) resolver.

  1. *-examples. Encontrar exemplos de hoje na web de tipos de conteúdo que acha necessário um microformato. Documente-os com URLs. Documente os esquemas implicitos que contêm exemplos. Esta é a ação que ajuda a seguir o principio 3, designado a humanos em primeiro, máquinas em segundo... adapteo atual ambiente para usar padrões.
  2. *-formats. Find widely adopted interoperable current data formats and standards that attempt to or have attempted to solve the problem previously. Document their explicit schemas. This is necessary prerequisite for following through with principle 4, "reuse building blocks from widely adopted standards".
  3. *-brainstorming. Use the current real-world web examples and their implicit schemas to determine an 80/20 as-simple-as-possible (principle 2) generic schema to represent their data. Yes, this means you will explicitly omit some features of some use cases, or perhaps entire use cases which are more edge-cases than representative of larger, aggregate/macro behaviors. See which existing microformats can be reused as building blocks (principle 5, modularity). Use those existing data formats and schemas as a source of names for the fields (principle 4). Consider how would you embed this microformat in other formats (also principle 5, embeddability). With an 80/20 schema, and a source of field names, write up one or more straw proposals for a microformat. Make sure the straw proposals encourage the decentralized distribution of data (principle 6). At this point, you may want to also consider a naming section, where various names for the microformat can be considered.
  4. **. When it seems like there is some amount of consensus around one of the straw proposals for a microformat(**), write it up as a separate wiki page as a draft specification.
  5. **-faq. Haverá perguntas comum sobre novos microformatos que podem/devem ser respondidas na página FAQ.
  6. **-issues. Folks may also raise issues about the microformat which aren't immediately addressable. An issues document helps serves to capture these issues, who raised them, and when, so that folks working on the microformat can be sure to go through and thoroughly answer them.
  7. **-implementations. Eventually there may be too many implementations of a microformat to document them in an informative section at the end of the specification, thus the list deserves its own page.

Movendo de Estágio para Estágio

Esses estágios de desenvolvimento são espelhados na página principal onde microformatos são divididos para "Discussão Exploratória", "Esboços" e "Especificações". Como microformatos movem de um estágio para outro? Para ajudar a responder essa pergunta, é provavelmente útil elogiar uma definição de desiredato para cada estágio.

Discussão Exploratória

Você precisa de um problema e você precisa tentar declarar isto. Você deve fazer isso nessa wiki usando os itens atuais sob discussão exploratória como um guia. Então envie uma nota para a lista microformats-discuss para obter a atenção dos outros que você está interessado em microformatos. Esta é provavelmente uma boa chance de puxar pessoas de fora da comunidade de microformatos atuais que podem também ser experiência do mesmo assunto.

Retorno provavelmente irá alcançar a gama. Outros podem desafiar sua indicação do problema, o necessário para um microformato, concordar, ou adicionar. Todo retorno construtivo é bom.

As a result of feedback, you may decide to abort your microformat idea or substantially modify it. One thing you want to be sure to do at this stage is to avoid reinventing the wheel. Are there elemental microformats you can reuse as building blocks? Doing this will save you effort and help you get implemented later because implementers will have less work to do.

However, do not be cowed from moving forward just because some people object. If you can find a group of people you respect who feel your idea has merit and, perhaps most importantly, are willing to continue working with you on getting it in shape, proceed.

Esboços

Aqui, você precisa escrever o que é essencialmente uma especificação, mas com a idéia que pode mudar bastante. Novamente, isto requer ir na wiki, e você deve enviar uma nota para o microformats-discuss para alertar pessoas que algo novo aconteceu. Não hesite em continuar tentando pegar uma resposta de recursos pertinentes fora da comunidade. Esboços precisam incluir ao menos o seguinte:

  • Opiniões a respeito do fato que você não patenteará e serão adotadas o apropriado copyright como ilustrado pelo esboço atual.
  • An XMDP stating attribute values. You may want to place this on a separate wiki page and link to it. In that case use the naming convention *-profile, e.g. hcard-profile.
  • Exemplos de práticas atuais que mostram como o microformato seria usado. Fique de olho pronto para como o microformato está atualmente melhorando as coisas. Se não está, talvez uma indicação que ou precisa abandonar ou mudar bastante.
  • Referenciar que recuam suas decisões de projeto do microformato. Na medida do possível, você não quer inventar coisas de whole cloth.
  • Uma lista de implementações (se houver).
  • Uma sessão de assuntos para pessoas para retornar à você com objeções detalhadas.

Especificações

Você geralmente precisará ao menos de uma iteração para ir além do estágio de esboço. No momento algo torna-se uma especificação, deve ser estável então deve ser estável de modo que desenvolvedor possa colher e escrever. Isto implica que há ao menos um par de implementações.

Antes de mover-se para a sessão especificações, solte uma nota para o microformats-discuss e aguarde um dia ou dois para maiores objeções. Se nada está disponível, mova-se o microformato para a area de especificações. Isso despertará qualquer editor adormecido, e eles podem mostrar sua objeção e mover a você de volta para esboço. Se você tem seguido o processo, agora é hora de conseguir definação. Nesse conjuntura, qualquer assunto restante deve ser fácil de resolver.

Outros Documentos

Padrões

Que tal outros tipos de páginas nesse wiki, como "padrões" (ex. include-pattern)?

Como esses são criados?

A curta explicação disso:

Os padrões não são formados ao todo. Eles não se sustentam por si próprio. Eles são meramente documentos de partes de outros formatos que são esperados para (ou é) existinte do reuso pelos outros formatos. Os exemplos do mundo real para inclusão de um parcipar foram documentados no contexto do resume-examples, resume-formats, e resume-brainstorming (como notado o documento) "Inicialmente desenvolvido como parte do resume-brainstorming..." Mais tarde, os exemplos do mundo real por revisões que foram encontrada para precisar de incluir padrões igualmente.

Relatado