Exigir que as pessoas usem github ou similar parece altamente fora de cogitação.
Se alguem quiser abraçar a causa de gerenciar issues, com github ou qq outra ferramenta, certamente ele nao sera proibido ou amarrado na cadeira. Abs, Oda Em 28/04/2015 08:59, "Peter Krauss" <[email protected]> escreveu: > OKBr's partidários do "tudo tudo tudo na lista", > > Existem também os partidários a levar parte das discussões mais > específicas (de projeto) ao *Github/okfn-brasil/PROJETO/issues* > do respectivo projeto... Entendo que somos minoria, mas não custa > confirmar (por favor manifestem-se). > > Coloquei "parte das discussões": existem sempre as mais holísticas, e a > sugestão de partir para os */issues* ou não é do pessoal que discute, não > tem regra... O importante, e que quero chamar atenção, é que *não deveria > haver barreira*. > > Abaixo um exemplo fresquinho de como se dá a dinâmica de uma lista com o > pressuposto de especialização nos *issues*. > > O Dan Bruckley é o gestor do projeto (no nosso caso poderia ser ou zelador > ou coordenador ou alguem da equipe), e ele, com alguns ajudantes mais > (usuários de github), incentiva a discussão geral na lista > (public-vocabs@w3c)... > Mas logo que ele percebe especialização ou chance de "formalizar pedidos" > (emissão de *ticket*), ele mesmo (exemplo anexo), se o assinante da lista > não estiver acostumado, consolida o discurso da lista num texto de nova > *issue*... > E assim vai: > > * discussões de *isssues* que crescem, podem voltar à lista; > > * discussões da lista que se especializam, mesmo sem ser "bug" nem "new > issue", ganham seu *ticket* (issue) com devido *label* > > * *Labels* são bem diversificados e bem controlados, para acomodar todos > os tipos de discussão especializada: ver > https://github.com/schemaorg/schemaorg/issues > > Essa é a minha leitura do "como funciona" (boas práticas para nos > espelharmos) uma *lista de discussão global acoplada às discussões > especializadas* e formalizadas (tickts) nas *Github/issues*. > > Peter > > > - - - - > PS: o fato de a própria lista public-vocabs já ser meio especializada não > compromete a analogia, pois o "global" deles é realmente aberto e envolve > um publico amplo. > > - - - - - COPIA DE MENSAGEM DA LISTA [email protected] - - - - - - - > From: Dan Brickley <[email protected]> > Date: 2015-04-28 8:14 GMT-03:00 > Subject: Re: Domain of schema:numberOfEmployees? > To: Sarven Capadisli <[email protected]> > Cc: W3C Web Schemas Task Force <[email protected]> > > > On 28 April 2015 at 10:41, Sarven Capadisli <[email protected]> wrote: > > On 2015-04-28 11:02, Jindřich Mynarz wrote: > >> > >> Hi, > >> > >> why is the domain of <http://schema.org/numberOfEmployees> set to > >> schema:BusinessAudience? Shouldn't it be schema:Organization instead? > > Thanks both. This is worth addressing. I've filed an issue: > https://github.com/schemaorg/schemaorg/issues/456 > > There is a natural temptation to try to generalize this further, but > (as I've argued in the issue tracker) things get complex quickly. > Adding Organization as an appropriate type for numberOfEmployees is a > quick and simple improvement. > > Incidentally it does also improve (very slightly) the possibility for > verifying certain kinds of information, or at least probing for > consistency. For example consider an Organization that has Ali, Bob > and Carla listed as 'employee'. If we also had numberOfEmployees: 3, > we would have some additional confidence that we have a complete > description of the organization's employees (at that time, at least), > whereas if we had been told numberOfEmployees: 2, we might instead > care to re-evaluate what exactly the data was telling us. Since > schema.org (and microdata/rdfa/json-ld) descriptions are always > partial accounts of a larger reality, having these simple count > properties can provide helpful checks. > > Dan > > >> Best, > >> > >> Jindřich > >> > >> -- > >> Jindřich Mynarz > >> http://mynarz.net/#jindrich > > > > > > Beside the point that the rdfs:comment only emphasizing on "business", > > looking at all of the rdfs:subClassOf schema:Organizations, it appears > to be > > that "number of employees" is suitable for all of them. > > > > I agree that domain schema:Organization seems more appropriate. Thinking > > ahead, are there organisations (currently undeclared) which do not have > > "employees"? > > > > -Sarven > > http://csarven.ca/#i > > > > > > _______________________________________________ > okfn-br mailing list > [email protected] > https://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br > >
_______________________________________________ okfn-br mailing list [email protected] https://lists.okfn.org/mailman/listinfo/okfn-br Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
