Re: [Fwd: Re: [Hillside Members:] [Fwd: [Fwd: pattern repository]]]

2 views
Skip to first unread message

Yishay Mor

unread,
Mar 7, 2009, 11:33:25 AM3/7/09
to Till Schümmer, pattern-x
Till,

thanks for relaying this. could you please relay my response to the list? for some reason I'm still not on it.

I have built two pattern repositories, and have just put in a grant proposal for enhancing the second - so if anyone is about to launch a new repository initiative, I would be happy to pool resources or at least share knowledge. Both projects are open source, so you're welcome to use our code. Our current repository is based on the XWiki platform. You can find it at:
http://patternlanguagenetwork.myxwiki.org
We're considering a migration to the curriki platform, which is an enhanced version of XWiki.

Our previous repository is at: http://lp.noe-kaleidoscope.org/ (under Outcomes/patterns). It has some interesting features which we haven't yet ported to the new one.

This issue had come up at EuroPLoP 2008, and as a consequence a mailing list has been set up for further discussions: patt...@googlegroups.com. I suggest we take the conversation there, and only report back to the main list when we have some conclusions. I doubt that the general audience wants to observe us going through the same old dance steps.

I won't go into a long discussion of the patterns I can suggest from my experience, but I'll bullet-point a few forces and considerations:

* What is your repository? Is it a database with powerful search? Is it a knowledge sharing platform? Is it a collaborative editing tool? All of the above? In any case, there are surely some generic patterns from the respective domains, and you should apply them. Before being a repository, it should be a good piece of software. So many times we focus on innovation and neglect the basics - and I'm not exempt from that sin.

* structure vs. flexibility: these are forces that need to be balanced both between and within patterns. A long table of patterns is unyieldly. It is tempting to impose some sort of tree structure. The problem there is two-fold, first differnt users will have different organisaional schemes in mind. Second, your own scheme will change over time. My recomendations would be to provide powerful search, support tags and rapis search / browsing by tags, and allow users to contribute maps of languages within the repository.
At the single pattern level, every pattern initiative that ever existed has gone through endless arguments about the optimal template. Simple templates afford rapid input and flexibility, detailed templates afford richer semantics. You will not get it right the first time, so make sure you can change the template over time - or ideally allow multiple templates. Another dimension to consider is soft vs. hard templates. "Soft" means the user can override the template, restructureing the patterns at will.

* Embedded vs. off-line editor: do I edit patterns in sito or do I upload word files? I think the forces are obvious, so I won't elaborate.

* Cenralisation vs. distribution: Anyone who ever built a repository had the fantasy that "if you build it they will come": I need a pattern repository, therefore the world needs a pattern repositiry, I build amazing software, therefore I will build the best repository ever, and everyone will store there patterns in it. Forget it. If that logic applies, you would be using my repoistory rather than building your own. Instead, lets focus on interoparability - I should be able to search your repository from within mine, and link to your patterns as related / super / sub patterns of mine. We have two RESTfull APIs for our repository, which allow you to browse / search it programatically.

* Social features and workflow: versioning, discussions, tagging, presence, messaging, user rating, etc. its a web2 world - don't embaress yourself by building a BBS.

Happy to continue this discussion eleswhere.

___________________________
 Yishay Mor, Researcher, London Knowledge Lab
  http://www.lkl.ac.uk/people/mor.html
  http://www.google.com/calendar/embed?src=yishaym%40gmail.com
  +44-20-78378888 x5737


2009/3/6 Till SchueŸmmer <till.sc...@fernuni-hagen.de>


-------- Original-Nachricht --------
Betreff: Re: [Hillside Members:] [Fwd: [Fwd: pattern repository]]
Datum: Fri, 6 Mar 2009 08:22:04 +0100
Von: James O. Coplien <jcop...@gmail.com>
Antwort an: mem...@hillside.net
An: mem...@hillside.net
Referenzen: <49AFD398...@wu-wien.ac.at>

It's not clear how garnering the wisdom of the crowd will keep you
from adding to the number of repositories... I think that a worthy
service that someone could provide right now is to bring together a
face-to-face gathering of people who have committed to building them
in the past, trading notes, and figuring out what joint direction best
serves the industry or at least the community.

Second, it's not clear to me that this is a worthwhile efforts. The
rules of thumb you apply to archiving the GOF patterns are certainly
not those I would want you to use in organizing the organizational
patterns. Most of your questions in fact don't make sense for the
organizational patterns, and those that do make sense will almost
certainly have different answers than for, say, patterns of
telecommunications system architecture.

In short, this might be a search for a common solution that doesn't
exist. Before assuming you should go ahead with it, you should make a
good, crisp, problem definition (what are you trying to achieve and,
when you're done, how will you know you succeeded?) before trying to
elicit answers such as you do below. I appreciate the goodheartedness
of the attempt. But I think that one thing that has killed most past
attempts is that they have not been inclusive enough. The ones that
have been inclusive have, I think, succeeded. One might consider Wiki
a success by most measures one would apply to this project. If you can
figure to do better than Wiki, well, those are high expectations.

I'd suggest taking a pattern approach: Get the community involved in
actually building it, rather than asking for requirements. Make it an
open source project. Start by building something simple and small (or
better yet, start with one of the dozens of repository approaches out
there - probably Wiki.) Then let it grow as its users add to it and
shape it.


On Mar 5, 2009, at 2:28 , Uwe Zdun wrote:

Posting this on behalf of Paris Avergeriou.

Best, Uwe


-------- Original Message --------

(apologies for multiple postings)

Dear colleagues,

as part of a research project, we are planning to build a publicly
available online repository for software patterns. In order to avoid
making YET ANOTHER pattern repository, we 'd like to use the "wisdom  of
the crowd" to avoid pitfalls and apply lessons learned. If you have  been
involved in the creation of pattern repositories, or have used them,  or
have ideas about them, can you please tell us all about it? The
questions we are interested in, include but are not limited to:

- What worked well and what didn't?
- How were patterns contributed in the repository?
- How were pattern solutions represented (e.g. UML diagrams)?
- How were patterns browsed?
- How were patterns searched for?

Best regards,

Paris Avgeriou and Uwe van Heesch



---------------------------------------------------------------------
To unsubscribe, e-mail: members-u...@hillside.net
For additional commands, e-mail: member...@hillside.net



---------------------------------------------------------------------
To unsubscribe, e-mail: members-u...@hillside.net
For additional commands, e-mail: member...@hillside.net


--
=============================================
Dr. Till Schuemmer

FernUniversitaet Hagen
Department of Mathematics & Computer Science
Cooperative Systems

Till.Sc...@Fernuni-Hagen.de
---------------------------------------------
Learn more about patterns for
computer-mediated interaction:
http://www.cmi-patterns.org/
=============================================

Reply all
Reply to author
Forward
0 new messages