Open pe3 opened 8 years ago
Osallistumisoje-dokumentti on varmasti tarpeellinen ja se kannattaa ensi tilassa tänne laittaa. Issuessa oli myös mainittu, että tämä rajapintamääritelmä on jo käytösså jossain ja näistä olisi hyvä myös olla tieto täällä, että pysytään kärryillä siitå mikä versio on käytössä ja misså laajuudessa.
Mulla ei ole tietoa, missä määritelmä on käytössä. Viitsisitkö @jjaone guugeloida tänne alustavan listan?
varmaankin vielä käyttö on ollut vähäistä, käsittääkseni Helsingin kaupunki ja 6aika ohjelma.
On Mon, Nov 30, 2015 at 8:53 PM, Petri Kola notifications@github.com wrote:
Mulla ei ole tietoa, missä määritelmä on käytössä. Viitsisitkö @jjaone https://github.com/jjaone guugeloida tänne alustavan listan?
— Reply to this email directly or view it on GitHub https://github.com/okffi/open-api-definition/issues/22#issuecomment-160723590 .
+358 44 337 5439 about.me/apoikola
Kirjoitin allaolevat ohjeet yhdistämällä holo-alfa
-teeman README.md -tiedoston ja ATXSass -sivuston CONTRIBUTING.md -dokumentit (soveltuvin osin). Teen allaolevasta vielä Pull Requestin niin saadaan asiaa eteenpäin.
Once the repository is cloned somewhere, cd
into that directory and run the
following commands. You only need to do install
once to get started, then use
update
very occasionally (if we ever update gems).
# Tools that must be installed globally.
$ gem install bundler
# first time
$ bundle install
# occasional updates
$ bundle update
To run a server that auto-generates the new site when you save files, run the following command at the root of your site (to start the Jekyll server).
$ jekyll serve
To run Jekyll in a way that matches the GitHub Pages build server, run Jekyll with Bundler. Use the command
bundle exec jekyll serve
.
When everything is OK, your site should now be available at http://localhost:4000
.
Hassua, miten eri suunnista samaa repoa voi katsoa. Mä ajattelin, että osallistumisohje - tietysti - koskisi vain sisältöön, eli määritelmän muokkaamiseen, osallistumista :-)
@pe3 Sisältöön liittyvät ohjeet kannattaa toki lisätä osaksi tuota uutta dokumenttia. Käytännön tasolla nuo teknisemmätkin ohjeet ovat silti tarpeen, jotta kaikki uudet osallistujat ymmärtävät työkalujen toiminnan sekä yhteistyön workflow -prosessien etenemisen.
Edelleenkin #opensource-projekteille tyypillinen kontribuutiomallin kuvaus puuttuu (siis nlmenomaan se miten siihen #AvoinAPI-määritelmään kontribuoidaan ) ja kuinka/ketkä siihen pääsevät vaikuttamaam ja kuka PR:stä ja committeista päättää ja ylipäätääm repon omistaa ja sitä hallinoida. Ja kuitenkin tunti sitten, mitenkään ratkaisua perustelematta 'omistajan elkein' tämä issue on suljettu ja asia muka ratkaistu vaikka mitään muuta ei ole tapahtunut kuin täällä on yllä esitetty muutama asiaan etäisesti liittyvä kommentti 5 kk sitten ... - ja nyt 'issue has been #closed by @Mygee'.. :/
Ei oikeen yhteisöllisyyden tunnetta synny, kun kontribuutiomallistakaan ei voi avoimesti edes keskustella vaan yksi ihminen päättää asiasta ja pitää sitä merkityksettömänä/tarpeettomana tai jotenkin ratkaistuna (vaikka ainakaan julkisesti ei ole mitään lisätietoa tähän tullut)...
Huom. suljetuissa FB-ryhmissä tai pienen porukan f2f-keskusteleissa kaveripiirin kesken tehdyt päätökset tai linjaukset eivät ole avoimuutta tai #opensource-yhteisöllisyyden mukaista, eikä tässä repossa ilmeisesti vieläkään ole License.md -dokumenttia (enkä muualtakin ole löytänyt tietoa siitä onko CC4.0:n mukainen tai GPL-yhteensopiva).
Pieni korjaus edelliseen kommenttiini; on tuolla repossa sentäään CC1.0-lisenssiteksti, mutta siis edelleenkin on kyseenalaista ja epäilyttävää, että millä perusteella @Mygee -tunnus on kontribuutiomallin puuttumiseen liittvän Issue:n sulkenut..?
On myöskin huomattava, että @d2s'n ehdotus/PR Contributing.md:si menee lähes täysin asian ohi, eikä liity mitenkään #AvoinAPI-määritelmän tekstiin ja sisältöön myötävaikuttamiseen ja/tai sen kirjoittamiseen osallistumiseen.
@jjaone No tee osallistumisohje / ehdotelma siitä. Katsotaan se sitten yhdessä (kaikki rajapinnan määrittelyyn osallistuneet henkilöt) läpi ja muokataan siitä sellainen, että ryhmä voi sen yhdessä hyväksyä tai hylätä riippuen siitä, mitä ihmiset ovat asiasta mieltä. Kyllä paras tapa osallistua on tehdä itse ja olla aloitteellinen, varsinkin kun niitä "kädet savessa tekeviä käsiä" on aina liian vähän. Kommentoi uusi versio avoimesta rajapinnasta (versio 1.1) samalla: https://docs.google.com/document/d/1BbQvmPwnFObYMcD_69zXqUdm3D7VPBViaWiDOyRHK5E/edit?usp=sharing.
Onko jossakin sanottu tai luvattu että tämän määritelmän muokkaamisprosessin pitäisi olla maksimaalisen avoin? Jos ajatellaan määritelmän kehittämistä pragmaattisesti, niin tärkeintä on ensimmäiseksi huomata, että määritelmä on jo jonkin verran käytössä, jonka lisäksi sitä on joidenkin potentiaalisten käyttäjien toimesta kritisoitu. Näitä kommentteja on @Mygee ansiokkaasti ulkoisen aikataulutriggerin hoputtamana kerännyt ja vienyt eteenpäin. Tällainen todellisen käytön mukaan ohjautuminen tuntuu tuottavan parempaa ohjaussignaalia ja merkityksellisempiä kontribuutioita kuin kaikille avoin GitHubin commit-prosessi.
Tämä issue on ollut puoli vuotta avoimena. Siinä ajassa kaikki halukkaat ovat kyllä kerenneet asiansa tähän issueen sanomaan ja tekemään. Näyttää siis siltä, että open-api-definition-projektin GitHub committaaminen ei vedä ja tämä issue rupeaa siksi näyttämään rönsyltä. On aivan normaali agile / open source -käytäntö, että rönsyjä jotka eivät näytä tuottavan arvoa ja sitoutumista karsitaan, sillä kokonaisuuden kannalta ne roskaavat projektia. Olen tämän issuen alunperin luonut ja mun puolesta tämän voi sulkea, ellei @jjaone:lla nyt ole viime hetkellä tekeillä jotakin.
GitHub:issa on tuki osallistumisohjetiedostolle.
Tähän mennessä määritelmän päivittämistä on vasta suunniteltu GitHub-issueissa. Koska määritelmä on jo käytössä Helsingin kaupungissa ja valtiolla, on määritelmän päivittämisen oltava hallittua. Git ja GitHub tarjoavat siihen hyvät välineet, jos vaan osallistujat saadaan mukaan opettelemaan työskentelytapaa. API:Suomi-ryhmässä keskustelua prosessista.