Beyond Pattern Repositories
From PatternForge
The title is meant to be provocative, to make us think that when building a Pattern Repository we need to create more than essentially a database for patterns. We also need to address issues like:
- Why should pattern authors contribute to the pattern repository?
- What value do users get from using the repository?
- How do we ensure the quality of the content of the repository?
- What incentives can we provide to sustain a repository (business model)?
- More Issues
This page is a space to carry out this discussion. Please add your own thoughts to this page. For now, we can keep the whole discussion on this page and refactor subtopics later as needed.
Contents |
[edit] Pattern Community System
Axel proposes an online Pattern Community System, which is "more than just a repository; it should be a community system with defined roles for its members". It is an issue of quality.
[edit] Producers and consumers
Informally distinguish producers and consumers of patterns. An author of a pattern is a producer, any person making use of a pattern is a consumer. Assume that the number of producers is considerably smaller than the number of consumers. Any member of the PCS can be a producer, a consumer, both, or none. In the beginning of the lifetime of the PCS, the number of members being producers will probably be higher than the number of members being just consumers
[edit] Outcomes and values
Desired outcomes:
- consumers get up-to-date information on patterns
- producers get reputation (or even money)
- wannabe-producers (e.g. researchers, pattern miners) get information on missing patterns/uncovered areas
Desired values:
- completeness: Any pattern ever described should be addable
- credibility: supported by at least five key players in the pattern scene
- openness: anybody can become a member
- searchable: several search dimensions should be supported
- Usability: pattern authors should easily be able to maintain their patterns (e.g. add a newly introduced tag to a group of patterns
[edit] Full patterns or descriptors
It should be possible to add a full pattern description (e.g. as a PDF file) or just the descriptor of a pattern, because some patterns are copyrighted when they are published in books or journals.
[edit] Roles
The PCS should be more than just a repository; it should be a community system with defined roles for its members. Why? Because it should not just contain a descriptor for each pattern, it should also contain qualified comments. A comment is more qualified if it comes from a person with a solid pattern reputation. Everybody should be able to make a comment, but not all comments should be equally weighted.
Possible roles:
- registered community member
- PLoP participant
- PLoP shepherd
- PLoP conference chair
- Pattern book author
[edit] Quality levels
Different quality levels for a pattern:
- 0: described in a paper
- 1: accepted for a PLoP conference
- 2: published in PLoP proceedings
- 3: published in a book
- 4: published in Transactions on PLoP journal
It should be possible to filter the patterns according to their quality level.
Only moderators should be allowed to raise the quality level of a registered pattern. All chairs of the PLoP conferences (todo: identify set of all chairs) should be moderators automatically. They can assign the moderator status also to other members of the pattern community.
[edit] Ownership, ISPN, and credit
Open questions:
- Concept of an owner of a pattern? Special rights?
- Unique identifier provided by the community system?
Unique Identifier (ISPN):
- Year of discovery (4 digits)
- Proposer id (9 digits, member id provided by PCS)
- Sequence number (4 digits, generated by PCS)
When registering a pattern, the proposer is first asked for the year and in return gets a new ISPN; he then is asked for the author of the pattern, which can be a different member. This way it is possible to register a pattern for another author who then can raise the quality level of the pattern depending on his/her role.
Misuse scenario: Member A wants to register a copyrighted pattern of another member B again, because the version already registered just contains descriptor information and A wants a version with full information to be registered (and accepts it to stay on a low quality level). If A gives at least credits to B, B can easily find out about it (any author can get an overview of his own patterns). If A does not give credits to B, B can find out about it via a search for patterns with the same name. In any case it should be possible to remove rights from member A, up to the removal from the community.
[edit] Fair Use, Tagging, WIki, and Interoperability
In an email, Till comments on some of the key issues a repository needs to address.
[edit] Legal issues
IMHO it is not fair use if problem/solution-patlets are copied directly. Creating own summaries seems fair but may also weaken the patterns. Best would IMHO be if authors contribute only their own content. I would at least try to ask the authors.
Michael comments:
- I am quite sensitive to that. So far we have only entered our own patterns or asked the authors for their approval when entering the patterns oursleves (see Pattern Collections).
- However, I would like to see a better solution in the future. For example, if authors defined what others can or cannot do with their patterns in the form of some license, the issues surrounding "reuse" would be much clearer. I am thinking along the lines of a Creative Commons license or similar.
[edit] Tagging
I think that this is a great idea.
Michael comments:
- There was good consensus in the group that tagging would be useful. Of course, there are systems that do that already (eg Ondrej's Pattron system) or the Agile Practice Patterns site.
[edit] Wiki
I'm not sure if the wiki is the best media for creating an on-line pattern repository. We were thinking about this when we designed the companion web site for our book but decided not to use a wiki because we wanted more process support including group moderation and more visible authors.
Michael comments:
- A wiki seemed like the least common ground initially. Our hope is to combine the collective knowledge we have in this group to define what kind of platform we need. There are, of course, a number of important trade-offs to balance, eg wrt openness or barrier to use.
[edit] Related work
This leads me to my own web site which may be related to your activities ;-) If you like, you can check it out at: http://www.cmi-patterns.org.
Michael notes:
- I like it a lot. You have anticipated many of the features we were planning to experiment with (links, annotations by others/non-authors: known uses, ratings, ...).
[edit] Interoperability
It might make sense to think about cross-repository links. If all repositories would provide a basic patlet format, we could even shadow the content of one repository in another. In the ideal case, we could have a set of basic web services that each repository should implement and that provides access to patterns stored in the repository (an analogy would be the web services offered by amazon to access book meta-data).
Michael comments:
- Fully agree. That is one way to strike the balance between trying to establish a central repository that everybody has to use and many "silo" solutions tailored to specific contexts of use. Web services would allow an even deeper linking between systems, while allowing them to evolve separately.
