Hi Rob, Just from code one cannot deduct the convention behind it, there are in theory infinite different conventions resulting in the same result. One of the two variants in the vote is a convention that yields to the results as in the code currently in github and bases on Andy's remarks in the discussion thread.
As a person active in both apache projects that aim to produce a vendor independent RDF API (clerezza, and incubating commons RDF) I aim for convergence of the two API projects. At Clerezza we plan a release of refactored core library that get closer (for now mainly in naming) to the classes in the github proposal. Now I am NOT saying that convergence needs adaptation on both sides, if what results from this project satisfies the technical requirements of clerezza then it shall replace the clerezza API. But if the two APIs shall evolve into one, even if it's just the clerezza API directing its evolution at least the direction should be known. I'm saying "we can meet in uppecase land or in lowercase land, let's discuss what's better and choose", the answer is "right now we are somewhere in uppercase land we don't tell you were exactly and we might change it later". With Clerezza hat on I'm saying: "Tell us the convention you are using, so we can follow it resulting in the same method and class names for what we have in common". With the PPMC hat on I'm saying: "Let's choose the best and most sustainable convention as early as possible". If the current code follows a convention (as you understand) then why not make this explicit? Not voting on the convention doesn't make things better for but worse, because having an explicit convention is much better than just some code that is defended against changes. It cannot be the apache way to produce faits accomplis outside apache and then rush for a first release in the incubator. Cheers, Reto On Wed, Mar 25, 2015 at 12:30 PM, Rob Vesse <rve...@dotnetrdf.org> wrote: > My understanding from the thread was that the current code base does > follow a convention (if not anyones preferred convention) and thus several > people have suggested that no change is necessary > > Lack of consensus is not a reason to force a decision via a vote. Winners > and losers affects the health of community because some community members > may feel aggrieved (whether rightly/wrongly) and this may manifest in > various ways depending on the individuals and affect the community in the > long run > > If a decision is important then it should be possible to reach some > consensus eventually even if the decision is contentious. If the decision > is unimportant and there is no consensus around it then there is no reason > to force a change for the sake of it > > Rob > > On 25/03/2015 11:19, "Reto Gmür" <r...@apache.org> wrote: > > >Hi Rob, > > > >It is true that there is no consensus in the community. Will there be a > >consensus? I doubt it and I regard the decision an unimportant enough that > >I hope everybody can live with either decision. So while technically we > >have winners and losers, I don't see how this affects the health of the > >community. > > > >For me, more important than having my preferred casing option is to have > >an > >agreed convention. So I prefer being a "loser" in that vote rather than > >having no decision at all. > > > >Your concern would be very justified, if there would be an ongoing > >development that could lead to a consensus making the majority vote > >obsolete. I however don't think anybody thinks we go on presenting > >arguments and considerations. So I think the vote is an effective way to > >end this potato-potatoe discussion. > > > >Cheers, > >Reto > > > >On Wed, Mar 25, 2015 at 9:37 AM, Rob Vesse <rve...@dotnetrdf.org> wrote: > > > >> /Mentor Hat On > >> > >> I strongly recommend against calling votes like the one below where > >>there > >> is clearly no consensus in the community > >> > >> If you've been following the recent thread on dev@community.a.o about > >> vetoes and votes much of the discussion centres around the fact that > >>using > >> a vote to force a decision does not make for a healthy community since > >>it > >> creates winners and losers > >> > >> http://s.apache.org/dev-veto-thread > >> > >> > >> Where there is no consensus asking for a vote only furthers the existing > >> disagreements > >> > >> The podling should be focusing on actual progress such as IP clearance, > >> finishing migration into the Incubator and getting a first release > >>prepared > >> > >> Rob > >> > >> On 24/03/2015 22:07, "Reto Gmür" <r...@apache.org> wrote: > >> > >> >From the discussion thread "Casing: RdfTerm or RDFTerm" [1] there were > >>two > >> >possible casing conventions for acronyms that found some support. I > >>would > >> >like thus to call for a vote to determine the preference of the PPMC. > >> > > >> >Variant 1: > >> >Acronyms are treated like normal words, i.e. only the first character > >>is > >> >uppercased. > >> > > >> >Variant 2: > >> >If possible acronyms are cased as they appear in the specs (default > >> >casing), if they appear in a position where an uppercase first letter > >>is > >> >required (and this letter is not uppercase in the default casing) then > >> >only > >> >this letter is uppercased, if they appear in a position where a > >>lowercase > >> >first letter is required then the whole acronym is lowercased. Where > >> >obvious readability improvements result a different casing can be > >>chosen. > >> > > >> >Please indicate your preference: > >> > > >> >[ ] I prefer variant 1 > >> >[ ] I prefer variant 2 > >> >[ ] I oppose to both > >> > > >> >The winning variant shall be voted for acceptance in a binary yes/no > >> >vote. > >> >This step can be skipped if a variant has a majority of the votes > >>already > >> >and nobody asks for the additional vote. > >> > > >> >The vote is open for 72 hours. > >> > > >> >Cheers, > >> >Reto > >> > > >> > > >> >1. > >> > > >> > >>http://mail-archives.apache.org/mod_mbox/incubator-commonsrdf-dev/201503 > . > >>m > >> >box/%3CCALvhUEUg5_xvkYJPUPBhtmbbYT2ns1XoHXrNZhd64od6h48jvA% > >> 40mail.gmail.co > >> >m%3E > >> > >> > >> > >> > >> > > > > >
