Hi, so we all agreed.
I wrote our agreement into text here, and cleaned up that page as far as I could: http://sourceforge.net/apps/trac/oscaf/wiki/OntologyMaintenance I would say: from today on, we have to turn bad tickets into good tickets, Here is the central point, copy-pasted into this mail: *Good tickets* * are like ticket:34 <https://sourceforge.net/apps/trac/oscaf/ticket/34> * discuss one change at a time * provide a precise patch to say what needs to be changed in which ontology *Bad tickets* * contain multiple wishes for changes, * affect multiple ontologies, * are written in unprecise prosa, * express a different idea how ontologies should be and ignore the design rationale existing within the existing ontologies, * say that they are /in a hurry/ and need to be /done today/ because /so much is at stake/, * insult committers, maintainers, or others, * end up in endless fruitless and tiring discussions. The task of a good maintainer is to turn bad tickets into good tickets: by *closing them as invalid*, *splitting them up into multiple tickets, each one a good ticket* (and then closing the bad ticket as invalid, linking to good tickets), *telling the community about our agreements here*, *being polite and helpful*, respecting the anger and frustration of programming in general that caused a contributor to file a bad ticket. best Leo It was Evgeny Egorochkin who said at the right time 24.11.2009 01:16 the following words: > В сообщении от Пятница 20 ноября 2009 23:32:06 автор Leo Sauermann написал: > >> ok, summary from my side: >> >> * patches are a welcome idea by Antoni, Sebastian, Evgeny, Roberto, >> but some say: not mandatory. >> > > +1 as long as it's defined as: provide patch if possible/applies to the > situation/can be useful, > > >> * maintainer has to reply to a patch within a week. >> agreed? >> (if all say yes, we work like this from now on) >> > > Some questions: > * I can afford to promise this. Can others like Antoni afford? > * Maintainer = one of maintainers or all maintainers? > * What if the only reasonable course of actions is to first obtain feedback > from parties affected? Or this means that all maintainers must take some > action(like clarify the question, ask for feedback) in case if this is needed > within 1 week? > > How about tickets stalled due to lack of follow up from the reporter or one > of > implementations(where required)? > > To be honest, I'm DESPERATELY LOOKING FOR an excuse to be able to make > changes > faster. > > In the current situation, there's a chance this would mean: > * me proposing a patch(X% of the time based on someone asking/complaining > about something; (100-X)% of time because I see this biting us in the ass > later) > * me replying that I like the patch and > * me making the commit and closing ticket. Essentially no peer review or > feedback. > > >> I would also say: >> patches do not have to be perfect, something like this is enough: >> >> "change nco: >> add: >> nco:PersonContact rdfs:subClassOf banana:Bananas. >> nco:Contact rdfs:comment "All persons are bananas in their brains." >> " >> >> We have an ontology language (RDFS, NRL and N3) for a reason: it gives >> us a clear langauge to speak. >> Such text is easy to write, but much more precise than prose. >> > > +1 If you are allowed to use some human (but precisely worded) language when > it makes sense. eg: use xxx:string intead of xsd:string all across the > ontology. > The preference of course goes to specific lists of triples to add/remove. > > >> all ok? >> >> the input and dicussion is good, we get somewhere, >> best >> Leo >> >> >> >> >> It was Antoni Mylka who said at the right time 19.11.2009 11:45 the >> >> following words: >> >>> Sebastian Faubel pisze: >>> >>>>> Form my experience, it's almost impossible to come up with a working >>>>> patch when suggesting something significant and especially when >>>>> requesting a feature. >>>>> >>>>> There are often lots of possible ways to implement something and >>>>> without the initial discussion, you get a 95% useless patch, especially >>>>> if you aren't a core developer. >>>>> >>>> I agree to the above mentioned - It should not be mandatory to send in a >>>> patch when filing a bug report. However, a patch can often serve as a >>>> concrete starting point for discussion on the mailing list. I mean, that >>>> from a patch people can outline concrete modeling weaknesses and offer >>>> concrete resolutions. One difficulty when designing ontologies is not to >>>> get off topic and stay focused on the problem at hand. I think that this >>>> is what really needs to be addressed. >>>> >>> +1. Discussing a patch is much easier. Even if the initial version is >>> 95% incorrect. We shouldn't require it, because that would alienate >>> potential external contributors. We should seriously encourage it though >>> at least among ourselves. >>> >>> Antoni Mylka >>> [email protected] >>> _______________________________________________ >>> Xesam mailing list >>> [email protected] >>> http://lists.freedesktop.org/mailman/listinfo/xesam >>> > > -- _____________________________________________________ Dr. Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +43 6991 gnowsis D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: [email protected] Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _____________________________________________________
_______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
