ExperimentalTechnologyTemporaryPageCluster is the idea of making PageCluster assignments temporary. That is, page clusters would disintegrate automatically after a certain period of time.
This page includes:
- A summary of arguments for and against it.
- A note on our present test for the idea.
- Different ways to implement it.
- How it would interact with RecentChanges.
- Off-topic discussion, to be placed elsewhere.
- Present discussion.
You should understand the basic idea of PageCluster before going far into this page.
Arguments
Pro:
- TemporaryPageCluster may reduce mental barriers to assigning pages to clusters.
- Putting a page into a cluster is a severe change. (In ways that, say, adding a category tag is not.)
- A page can only be in one cluster at a time.
- Clusters affect RecentChanges. It's a big change that has implications for PeerReview. (That is, it is a big deal.)
- Making changes temporary may put people at ease with assigning PageClusters.
- If you do something wrong, it's not all that bad- it'll go back anyway.
- The association between a page and it's cluster is temporary.
- (This is a recurring theme of difference; See ClusterAsMetaData?...)
- example: We may have a spat, talking over someone's FrontLawn. We move it into a PageCluster. The conversation will use many pages, that probably have meaning and existence independent of the particular spat. examples: RoleOfLeader?, RelationshipBetweenThisWikiAndThatWiki?.
- Group interest can be fickle. We will be dismantling lots of PageClusters if we don't make the dismantling automatic.
- If you know beforehand that the cluster will be temporary, you don't want to have to remember to de-tag the clustered pages.
- Tripping old clusters may be bothersome, or even socially awkward.
- If an old flame war was clustered, and then someone pulls a page that happened to be part of the flame war, suddenly the whole flame war is revived. If it was automatically dismantled, then there is no problem.
- After a period of time, people work on the same page in a different way. "Different perspective, same page."
Con: Principally, Wiki:YouAintGonnaNeedIt.
- The time for a page to de-cluster is arbitrary.
- It doesn't matter if a page is temporary or permanent:
- Old pages (that de-clustering would affect) aren't showing up on RecentChanges anyway.
- You can remove the tag when you want to use the page, but don't think it belongs anymore.
- Some clusters should be permanent, e.g.
- a long-term project.
- a slow-developing interest, where updates are sporadic. (ex: FacetWiki)
- Pages are likely to belong to the same cluster until their content changes significantly.
- Thus, no value in breaking out of the cluster after some time passes.
- If the content does not change, the cluster is still valid. Automatic unclustering should only be happen when the page content changes; and when it changes, the person writing the change can also uncluster the page, if he feels that is the correct thing to do.
- Accidentally tripping old contexts is good: if it was worthy of a cluster, there needs to be closure.
Test Period
We eventually decided to use PageCluster aggressively, right now, as if we had TemporaryPageCluster. If we find problems with "tripping" clusters in the future, and find it's a problem worth solving, we'll revisit TemporaryPageCluster.
OffTopic
There is good discussion that is OffTopic for this particular page.
The super discussion is "how do we lower the barrier to PageCluster use," and, "is this something we really want to do, anyway?"
- One strategy is ClusterAsMetaData?.
- Another strategy is to have a better system for visualizing changes to pages as they move in and out of clusters. If re-tagging pages is common, people may refrain from both tagging and de-tagging pages, because they don't want to flood RecentChanges.
- The discussion about how PeerReview works when you have PageCluster technology should be: PeerReviewAndPageClusters?. It is part of an even larger discussion about RecentChangesVisualization?. (If links already exist for these concepts, by all means, please relink..!)
Mechanisms
Ways of implementing TemporaryPageCluster:
- By way of ExternalPageClusterAssignments?.
- By way of RdfForWiki.
- With a per-page time-out. After 30 days of non-use in the cluster, the page automatically drops out.
- With a per-cluster time-out. After 30 days of non-use, the entire cluster disintegrates.
- Single-edit clustering. A page change appears in a cluster for a single edit only.
- If the page belongs to another cluster, that's ok- for the single change, the edit appears in the other cluster.
TemporaryPageCluster Visualization
How would (putting things in, pulling things out) of a TemporaryPageCluster appear on RecentChanges?
LionKimbro thinks:
Discussion
I worry that the single-edit clustering might be troublesome. If the page is already in a cluster, and all of the sudden, there's a bunch of text in it, and nobody was notified- it's like, "WTF?!" At least, I'd be surprised.
I'd want the change to appear in both clusters, if it was assigned to one, but temporarily used in another. (PeerReview) -- LionKimbro
ChrisPurcell- I think you are right about long-developing interests, and long-term projects. However, I think I am also right. I think we are both right. There is a hidden Easter egg in here, I think. Some clusters seem to be permanent, and some seem to be temporary. Or perhaps we want something like-a-cluster, not-a-cluster. Hmm... -- LionKimbro
Is everybody happy with the reworking? Does anyone mind if I delete "Reworking Notes"?
Moving the OffTopic discussion off remains to be done. -- LionKimbro
- We might work HighRoadLowRoad into this page, instead of Wiki:YouArentGonnaNeedIt. Basically, I think TemporaryPageCluster is a high road, doing things by hand a low road, and as the Meatball page points out, it's highly debatable which one is best. -- ChrisPurcell
I think y'all are right; Now that I've played with PageCluster as if it were a TemporaryPageCluster, I'm not sure that TemporaryPageCluster is really necessary.
I think the most important counter-argument is:
- Some clusters should be permanent, e.g.
- a long-term project.
- a slow-developing interest, where updates are sporadic. (ex: FacetWiki)
But, I think we should keep this page in mind, because we haven't dealt yet with switching clusters, and things like that. In a couple months, we should be in a much better position (I think) to see how that works.
I don't think it'll be a problem, but it might be.
-- LionKimbro
I'd like to note two things so far, in favor of TemporaryPageCluster:
These are by no means conclusive points.
However, the second does erode on "clusters for slow-developing interests." If the interest is slow-developing, then why does it need to belong to a cluster at all? If there is one hit a day, there is no abbreviation of RecentChanges.
-- LionKimbro
I agree with the observation. But I think you could draw different conclusions:
- In these two cases, there is no need for a page cluster in the first place. Let us uncluster the pages again.
- Alternatively, the page cluster saves us some time thinking about what a given page is about. It acts like a category tag, and instead of saying "please note that page X changed" it says "if you are interested in Z, please note that at least one relevant page changed". RecentChanges is not smaller but easier to read.
I'm not sure what conclusion to draw, yet. -- AlexSchroeder
Having the RC for ExperimentalTechnology all in one place is quite convenient, since we need to refactor all these pages periodically. -- ChrisPurcell
I do think it's neat that, on the way to the page "TemporaryPageCluster," I also get a flash review of the discussion around this page. However, it's not really the temporal arrangement that interests me so much. For example, if it were a raw spacial arrangement of titles, I'd be extatic, and feel no loss.
I agree that it is still too early to draw conclusions. I wouldn't want to de-cluster these pages, by what I was just saying. -- LionKimbro
Raw spatial arrangements are hard to do usefully, I assert. Certainly, if we want to replace simple temporal sorting, we would need to think hard about a more useful alternative. -- ChrisPurcell
CategorySyndication