Re: library(ugraphs)

Dear Jan,

I am not sure there are that many examples of out-right rudeness in the list.
On the other hand, and in my opinon alone, there seems to be a good deal 
of bulldozing.

The discussions on Swi 7 were the highlight of the decade in this respect.
I was all in for all changes and probably instigated some of them.
But I wasn't at all sure some interesting alternatives were discussed,
and the reason wasn't (mostly) outright rudeness but just volume of dissent about
the why and disregarding that some of us would have preferred to discuss the how.
As far as I am concerned there was a turning point in this discussion-
where with pure misinformation even great people were incited.

In any case, one of things  i took issue with was that you seem unwilling to take any 
lessons from the Swi-7 discussions.

Your 2nd and 3rd issue are best taken on together.
The way the credits work, they leave little room to move forward
with sharing decisions, and the way decisions are taken make little 
necessity for much change in credits. Your wiki argument is not all that strong.
you expect the contributors to ask to be added or add themselves ?

I dont think anyone disputes that you should have the final, or even the only vote
in technical matters. I certainly consider myself a beneficiary of this, as i had some if not a lot 
of suggestions included, regardless of how dismissive you were at first.
The whole point is to explore how/whether Swi would benefit from becoming more open on 
the fringes so you can have more time to concentrate on the core.
Swi has acres of stuff that is currently under utilised because there is no easy way in
for the novice. Your ability to produce industrial strength software at 
industrial rates, is not matched by the documentation and tutorials. 
We should be talking about how to improve this, not about misplaced sensitives from the past.

As i might have mentioned in the previous email, my own interests are primarily in open prolog 
as a vehicle for general purpose programming. It is just so, that Swi/Yap is/are in unique 
position to move this forward. If you want to consider a (more?) collaborative project,
it might be useful if you take one step back and consider

	what is the point ? (of Swi, particularly as an semi-open project)

	peoples 

	disengagement of the engine to the platform

	how-tos, book, tutorials (web page already is a huge improvement)
	

If you are interested to talk about any of this and the ones from before, of course I will be contacting you
offline.

Regards,

Nicos.


On Mon, 17 Feb 2014 15:17:46 +0100
Jan Wielemaker <[email protected]> wrote:

> Dear Nicos,
> 
> Although I knew you were struggling with these issues, your reaction
> still comes a bit as a shock. I think it boils down to three things
> (without a particular order):
> 
>    1. Rudeness on this list
>    2. Lack of credits for contributors
>    3. One man show in decision making
> 
> I think (2) is the easiest to `fix'. In general I try to give credits
> generously in source, changelogs, documentation, etc. Detached pages
> such as `contributors' easily get out of sync with reality. It is a wiki
> page though and suggestions are typically realized. Suggestions to
> further improve practice here is of course welcome.
> 
> Everyone on this list, including me, is responsible to keep discussions
> on this list respectful.  I think that many of us try.  Still, we should
> try harder.
> 
> (3) is a difficult issue. I have tried to improve the situation using
> packages and packs (confusingly). This makes it easier to have
> different people responsible for different fairly independent
> extensions. The packages have to comply with documentation, portability
> and stability requirements and the packs are completely open. Both seem
> to work to some extend. Ideally they should be integrated technically,
> so packs can become packages and visa versa easily. The pack playground
> is growing and slowly requires better infrastructure for search, etc.
> Possibly there are also opportunities for more credits here.
> 
> Decisions on modications and extensions is something I try to delegate
> to people who know more about it. For what triggered this, we have one
> clear expert here for the classical Prolog libraries: Richard. He wrote
> (or was involved some other way) many of these libraries. The other
> thing that drives this development is compatibility to YAP and SICStus.
> 
> I try to maintain a reasonably coherent and stable system comprised of
> the kernel, libraries and packages. As we have seen with the V7
> discussion, that is a delicate and fiercely debated process. I'm happy
> to discuss the possibilities for a more open process, but I do not
> believe in a one man one vote system here. I am a kind of dictator, but
> the country has open borders and anyone can clone it and start a new
> government.  That is a pretty good guarantee to restrain the powers of
> the dictator.  This architecture is not uncommon in the open source
> world.  AFAIK, Linux works that way (although it has a hierarchy of
> people in charge).
> 
> Yes, you are right that the system is at a junction point. There are
> several options along several dimensions though. The only thing that is
> really fixed is that the system will remain open source. Your input on
> this is appreciated.
> 
> I'd like to discuss this further with you offline (Skype?)
> 
> 	Cheers --- Jan
> 
> 
> On 02/15/2014 05:45 PM, Nicos Angelopoulos wrote:
> >
> > Dear Jan, all,
> >
> > On Thu, 13 Feb 2014 14:21:09 +0100
> > Jan Wielemaker <[email protected]> wrote:
> >
> >> On 02/13/2014 10:57 AM, Nicos Angelopoulos wrote:
> >>>
> >>>
> >>> Dear all,
> >>>
> >>> 1.
> >>>	library(ugraphs)  seems to have lost documentation for a number of its predicates-
> >>>	http://www.swi-prolog.org/pldoc/doc/swi/library/ugraphs.pl
> >>>	probably due to a very recent change as my local spuds server had full documentation
> >>>	until the last update from pl-devel
> >>
> >> This is a common issue with libraries that are partially documented in
> >> the source, but for which the `official' documentation is still in
> >> LaTeX. The complete docs are in
> >> http://www.swi-prolog.org/pldoc/man?section=ugraphs. The long term
> >> solution is to move the docs to the source and generate the LaTeX from
> >> there as is done for quite a few libraries, notably the ones under more
> >> active development.
> >>
> >> If anyone likes to help, submit patches that move the documentation from
> >> the LaTeX source into the library.
> >>
> >
> >		I would be interested to contribute, and I sense other people would as well.
> >		however the current framework is that the project is own entirely by you, with contributions
> >		being ad-hoc and any credits depending on you having time to document them.
> >
> >		As i don't want to speak about other people, I ll speak about myself.
> >		In my case I want to believe I had had a number of positive contributions,
> >		both in technical terms and over-all direction of the project.
> >	   The only mention i get in the contributors page is for the R interface,
> >		which doesn't even have a link to real.
> >
> >	   I think you are at a junction point. Continue being the full owner and keep
> >		Swi as a tight unit, or open up to user's high level influence and work
> >		to further integration with Yap, ideally with contributions from Prolog
> >		developers that have been open to collaborations (recent developments have
> >		shown that this is not an empty set).
> >
> >	   I believe, you have claimed a number of times that the fact that Swi is an one-man-show
> >		does not affect its merchantability- i think you are wrong. And in any case,
> >		we should be aiming to follow the example of projects such as,
> >			python            http://www.python.org/psf/about/
> >			R                 http://www.r-project.org/contributors.html
> >			bioconductor      http://www.bioconductor.org/about/core-team/
> >
> >
> >		The case of bioconductor is particularly interesting. I don't think this is the
> >                  right time for a in-depth analysis, but I strongly advice people to
> >		study the way in which they have set up the project.
> >
> >	   This list should be about discussing and inspiring to achieve the
> >		resources these projects have claimed, because prolog is absolutely 100% more
> >		important project than any of the above.
> >
> >>> 2.
> >>>	i am not sure if this is of general enough interest to be included in the library,
> >>>	but i recently coded a sub_graphs/2 predicate
> >>>	this includes a use case for the ord_select/3 predicate discussed previously
> >>
> >> Richard often has good remarks about such issues ...
> >>
> >>	Cheers --- Jan
> >>
> >
> >	I think it is important that we start looking towards the next 20-30 years and not to the
> >	past 20-30 years. Your loyalty and tenacity is admirable, as in the case of xpce though,
> >	it can be misplaced. I don't think the talk-to-my-mate type of approach is the best route
> >          for people suggesting extensions.
> >
> >	The past 15 years I had to defend things some of which was quiet trivial.
> >	Trivial, not because I am a good programmer, but because i had to face the problems,
> >	while using prolog to solve research problems. And it is frankly boring to explain
> >	things to people that think they know it all when they understand little of the evolving challenges.
> >	Things I welcomed if not advocated include,
> >			long integer rational arithmetic  (15 years ago i implemented a prolog version in clp(pfd) [1],
> >			                                Swi got those thanks to company funding AFAIK [2]
> >														  when i emailed about this I was lambasted with a sermon about the beauty
> >														  that is floating point arithmetic- if i recall correctly)
> >			bridge to R/DSLs                   [3,4]
> >			web services (particularly documentation lately)   [5,6,7]
> >			databases                          [5,8]
> >			package manager                    [9,10,11,12]
> >			strings                            [13]        (you forget so quickly)
> >			bioinformatics                     [14]
> >                          probabilistic logic programming     [15,the best part of a dozen publications]
> >
> >	The climate on the list would appear to that  we "common users" have to convince you and your informal committee of any
> >	changes we dare to propose. You know what? no we don't "have" to. We are trying to improve a great tool
> >	while at the same time we are grappling with our own understanding of logic programming and ourselves as lp practisioners.
> >	This does not happen by reminiscing about what happened 20 years ago. It is not a matter of "cleverness". It is a
> >	matter of been involved in pushing prolog to fit in the current computational landscape.
> >
> >	My firm belief is that the vast majority of list readers want a less aggressive less
> >	negative list that looks to the future. 99.9% of people contributing, contribute in this framework.
> >	A number of us, use prolog as a professional tool and since we feel incredibly lucky and in great debt
> >	to you for maintaining SWI Prolog, we try to contribute in discussions and suggestions.
> >	However, we are people that depend on contracts and contacts so we are not that keen
> >	to start "flame" wars and unpleasant exchanges. People that earn their living differently, might feel differently.
> >	Personally I have included SWI in a number of job applications but apart from my own
> >	website there is very little to support a positive association between my name and SWI.
> >	It was more likely that perspective employers will find negative comments attached
> >	on my postings to the list. These are just words to people that do n't have to look for contracts or work.
> >
> >	The last few years, I have been reasonably active in this list and have made it
> >	clear that my interest was spurred by the collaborative work with Yap.
> >	I have admitted to misusing this list as a forum for open.pl.
> >	In this direction I have been proposing to form a group of people that can
> >	more flexibly deal with expansions to built-ins and standard libraries.
> >	However from your advice above and lack of response to my plight show that I am fighting
> >	a loosing battle. For the next 2-3 years it is more likely you will fall back to
> >	the pattern that have served you well so far, despite the efforts of a group of users.
> >	Maybe in few years, our collective older age will bring a different approach.
> >
> >	From the perspective of the travelling prolog man, the bleeding obvious route to open prolog
> >	passes through
> >			agreement with Yap on an n-points engine replacement platform
> >			    changes at the points happen only in agreement, outside the engine changes communicate
> >				 both ways on trust
> >			SWI threads in Yap, best person for this is the SWI implementor of threads
> >			form a group of people for the husbandry of prolog as a general purpose programming language
> >			alternative n-point engines implement in non-C languages
> >
> >	The idea that I have to convince anyone of this is lucrative. I rather talk biology with biologists and stats with statisticians.
> >	If there is ever appetite for forming such a group and people feel I can be of help, I ll be glad to join.
> >          I am open to work with all kind of people as far as we understand where we all stand.
> >	In the meantime, I have removed myself from the mailing list for the time being, as i seem to have lost the war- or at least the bet with myself.
> >
> > So long, and thanks for all the (Thai) fish,
> >
> > Nicos
> >
> > [1] http://stoics.org.uk/~nicos/pbs/Ismis03.ps.gz
> > [2] http://www.swi-prolog.org/man/arith.html
> > [3] http://stoics.org.uk/~nicos/pbs/padl2013-real.pdf
> > [4] http://stoics.org.uk/~nicos/pbs/wlpe2012-JW.pdf
> > [5] http://stoics.org.uk/~nicos/pbs/wlpe2010.pdf
> > [6] http://stoics.org.uk/~nicos/sware/spuds
> > [7] https://lists.iai.uni-bonn.de/pipermail/swi-prolog/2013/010842.html
> > [8] http://stoics.org.uk/~nicos/pbs/padl2013-prosqlite.pdf
> > [9] https://lists.iai.uni-bonn.de/pipermail/swi-prolog/2012/008260.html
> > [10] http://comments.gmane.org/gmane.comp.ai.prolog.swi/17672
> > [11] https://lists.iai.uni-bonn.de/pipermail/swi-prolog/2012/009444.html
> > [12] https://lists.iai.uni-bonn.de/pipermail/swi-prolog/2014/012240.html
> > [13] https://lists.iai.uni-bonn.de/pipermail/swi-prolog/2012/008998.html
> > [14] http://stoics.org.uk/~nicos/pbs/wcb2012.pdf
> > [15] http://stoics.org.uk/~nicos/pbs/
> >
>