[Xesam] we agree on proposal to work towards "one patch per ticket" - DONE.

Fri Nov 27 01:28:54 PST 2009

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
>>> antoni.mylka at gmail.com
>>> _______________________________________________
>>> Xesam mailing list
>>> Xesam at lists.freedesktop.org
>>> 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:  leo.sauermann at dfki.de

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
_____________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xesam/attachments/20091127/b8551685/attachment.html 