Hi, folks,
Recently Lila had talk about #1 challenge in this mail-list which is related to participation. I want to recall Ward Cunningham's idea of observability in the very early days of wiki invention to address the possibility to enhance participation of Wikipedia today.
If you visit the early page of c2.com, you will find the idea of observability is one pillar principle of wiki software, and just follow the idea, Ward invent the RecentChanges for all wikis.
At that time c2 is very small; now Wikipedia is so big. The original idea of RecentChanges is not very effective today. We had made some extension for the original idea in our mediawiki software, but I think the step is too small.
Let's first take a look of what we had already invented are similar to RecentChanges but more effective:
* Wikizine or Signpost: community stories every week * some part of a Portal: recent changes under a subject compiled by human
Still possible for other kind of RecentChanges which is not invented yet, for example: * References and external links are very valuable resources, why not extract them from articles and compile them into a timeline?
Content is only one aspect to observe, people are another: * Who are the experts on some topics? * Who are my buddies on some articles? * Who did help me to improve an article originally I wrote?
In all, we may reshape our technical infrastructure in this direction for new spaces of participation. And finally, one open question for the system designer:
* Towards better content and community, what is the most important things we want our user to observe?
Regards, Mingli
On Thu, Jun 5, 2014 at 10:43 AM, Mingli Yuan mingli.yuan@gmail.com wrote:
- Towards better content and community, what is the most important things
we want our user to observe?
Mingli,
Thank you for raising this excellent and important question.
I have long maintained -- and I think many others agree -- that the idea of a monolithic "English Wikipedia" or "Wikimedia" community is, at best, an anachronism. While we can look at places like this email list and similar venues and see community behavior, that community is much better described as "Wikimedians who choose to spend their time on broad discussions" than it would be as "Wikimedians."
The choice to spend time on broad discussions does NOT lead to a representative sample of the larger whole.
Instead of trying to figure out how to improve the non-existent "Wikimedia community," I would say it is absolutely essential that we find ways to support the many, many sub-communities in our universe. These overlap of course, but they are distinct and, I believe, much more important. To name a few kinds of sub-communities: * WikiProjects (some of them) * Wikipedia in languages that have smaller communities * Wikimedia projects that have smaller communities (e.g., English Wikisource) * Administrative communities on projects, e.g. Commons (note, I said administrat*ive*, which should not be restricted to those who have the administrat*or* rights) * Those doing GLAM outreach
etc. etc. etc.
If we are going to focus on what supports thriving communities, we must engage with the questions -- and the existing research -- around smaller, more genuine sub-communities like these.
To date, I would say nobody in the Wikimedia movement -- least of all the Wikimedia Foundation -- has done an effective job of identifying and exploring the right questions -- much less coming to the right conclusions.
How can we shift the focus of our social interventions in this direction, effectively?
Pete [[User:Peteforsyth]]
On 6/5/2014 10:43 AM, Mingli Yuan wrote:
If you visit the early page of c2.com, you will find the idea of observability is one pillar principle of wiki software, and just follow the idea, Ward invent the RecentChanges for all wikis.
At that time c2 is very small; now Wikipedia is so big. The original idea of RecentChanges is not very effective today. We had made some extension for the original idea in our mediawiki software, but I think the step is too small.
Let's first take a look of what we had already invented are similar to RecentChanges but more effective:
- Wikizine or Signpost: community stories every week
- some part of a Portal: recent changes under a subject compiled by human
I think this is potentially a very interesting topic. I did think it was curious that the Signpost would be one of the first things that came to mind, since I wasn't really thinking about RecentChanges as a model when I created it. And in general, it's interesting to note that these examples all involve human work product rather than software features, even though RecentChanges is a software feature.
RecentChanges is definitely a core element of what we understand wiki software to be, so it's a good place to start. And there have definitely been other features in MediaWiki that extend the idea in ways that (for some purposes) may be more effective. Examples might include:
* Logs (essentially a filtered version of RecentChanges based on events meeting predefined criteria) * Watchlists (another filtered version, but this time based on user-defined criteria)
I invite people to brainstorm more examples of this principle at work - Pete's were again primarily social and community-based, but at this level of discussion we should be looking at both social features and technical ones. That would be a useful exercise with which to reexamine where we have gaps, and identify opportunities for new applications.
In all, we may reshape our technical infrastructure in this direction for new spaces of participation. And finally, one open question for the system designer:
- Towards better content and community, what is the most important things
we want our user to observe?
Well put. This is a critical issue that we should work on answers for in order to plan future development, both social and technical.
--Michael Snow
On Thu, Jun 5, 2014 at 11:05 AM, Michael Snow wikipedia@frontier.com wrote:
Pete's were again primarily social and community-based, but at this level of discussion we should be looking at both social features and technical ones.
YES YES YES!
However, the current priorities of the Wikimedia Foundation do not include that line of inquiry.[1] I think that is a very big problem.
-Pete [[User:Peteforsyth]]
[1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
On 6/5/2014 11:11 AM, Pete Forsyth wrote:
On Thu, Jun 5, 2014 at 11:05 AM, Michael Snow wikipedia@frontier.com wrote:
Pete's were again primarily social and community-based, but at this level of discussion we should be looking at both social features and technical ones.
YES YES YES!
However, the current priorities of the Wikimedia Foundation do not include that line of inquiry.[1] I think that is a very big problem.
-Pete [[User:Peteforsyth]]
[1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
Whether that properly characterizes the shift in priorities is probably open to interpretation, but I think that's a separate debate that would be best for another thread. At the strategic level in which this discussion operates, though, certainly all areas are open to exploration.
I also don't believe that social and technical aspects can always be neatly separated. I'm guessing you don't either, but avoiding it becoming a dichotomy is one reason I'd rather this not become an exercise in choosing sides just yet.
--Michael Snow
On Thu, Jun 5, 2014 at 11:33 AM, Michael Snow wikipedia@frontier.com wrote:
I also don't believe that social and technical aspects can always be neatly separated. I'm guessing you don't either,
Correct, I don't.
I'm not looking to pull the discussion immediately toward the WMF's strategic framework, but rather to point out early on that these things connect. I do think it would be a good idea to bring the two together at some point, but you're right -- there's a lot to be discussed first.
Pete [[User:Peteforsyth]]
On 5 June 2014 19:33, Michael Snow wikipedia@frontier.com wrote:
On 6/5/2014 11:11 AM, Pete Forsyth wrote:
On Thu, Jun 5, 2014 at 11:05 AM, Michael Snow wikipedia@frontier.com wrote:
Pete's were again primarily social and community-based, but at this level of discussion we should be looking at both social features and technical ones.
YES YES YES!
I also don't believe that social and technical aspects can always be neatly separated.
The common separation between UX and community/social concerns inspired me to choose "Social Machines https://wikimania2014.wikimedia.org/wiki/Main_Page/Social_Machines" as a theme for Wikimania this year, a term invented by Nigel Shadbolt, Tim Berners-Lee et al and defined thus:
"Once upon a time 'machines' were programmed by programmers and used by users. The success of the Web has changed this relationship: we now see configurations of people interacting with content and with each other, blurring the line between computations performed by machine logic and algorithms, and those that result from input by humans, arising from their own psychological processes and life experience. Rather than drawing a line through such Web-based systems to separate the human and digital parts (as computer science has traditionally done), we can now draw a line around them and treat each such compound as a 'social machine', a machine in which the two aspects are seamlessly interwoven."
The thing I especially like about the "machine" metaphor is the implication that they are things that can be fixed :)
*Edward Saperia* Chief Coordinator Wikimania London http://www.wikimanialondon.org/ email ed@wikimanialondon.org • facebook http://www.facebook.com/edsaperia • twitter http://www.twitter.com/edsaperia • 07796955572 133-135 Bethnal Green Road, E2 7DG
Sorry for re-activate this thread again, this time I want to address the observability on social networks.
Today content of or links to Wikipedia are spread all over the web. So the observability are not limited only for Wikipedia users, but for the whole internet users.
Let's take a look what happened if a wikipedia link posted on twitter, * https://twitter.com/mountain/status/483856113364762626
It is a bare link, not user friendly.
By contrast, please take a look at * https://twitter.com/mountain/status/483858990573441024
It is a NYT article with photos and abstract.
The technical things behind this are OpenGraph or something like this. The content provider label their own content with some metadata. And Twitter/Facebook/etc will show a rich content on their timelines.
I think we should embrace social, but it do not means social interactions only inside our own project, we should be social-friendly for the whole web.
A more detailed proposal - knowledge card.
Knowledge card is an overview of a wikipedia article, it can be used in many ways:
* it can spread easily on the social networks * from it, we can derive a more human-friendly timeline of wiki changes * etc
Regards,
Mingli
On Mon, Jun 9, 2014 at 11:02 PM, Edward Saperia ed@wikimanialondon.org wrote:
On 5 June 2014 19:33, Michael Snow wikipedia@frontier.com wrote:
On 6/5/2014 11:11 AM, Pete Forsyth wrote:
On Thu, Jun 5, 2014 at 11:05 AM, Michael Snow wikipedia@frontier.com wrote:
Pete's were again primarily social and community-based, but at this
level
of discussion we should be looking at both social features and
technical
ones.
YES YES YES!
I also don't believe that social and technical aspects can always be neatly separated.
The common separation between UX and community/social concerns inspired me to choose "Social Machines https://wikimania2014.wikimedia.org/wiki/Main_Page/Social_Machines" as a theme for Wikimania this year, a term invented by Nigel Shadbolt, Tim Berners-Lee et al and defined thus:
"Once upon a time 'machines' were programmed by programmers and used by users. The success of the Web has changed this relationship: we now see configurations of people interacting with content and with each other, blurring the line between computations performed by machine logic and algorithms, and those that result from input by humans, arising from their own psychological processes and life experience. Rather than drawing a line through such Web-based systems to separate the human and digital parts (as computer science has traditionally done), we can now draw a line around them and treat each such compound as a 'social machine', a machine in which the two aspects are seamlessly interwoven."
The thing I especially like about the "machine" metaphor is the implication that they are things that can be fixed :)
*Edward Saperia* Chief Coordinator Wikimania London http://www.wikimanialondon.org/ email ed@wikimanialondon.org • facebook http://www.facebook.com/edsaperia • twitter http://www.twitter.com/edsaperia • 07796955572 133-135 Bethnal Green Road, E2 7DG _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Thanks for the addendum. :-)
Mingli Yuan, 01/07/2014 08:44:
The content provider label their own content with some metadata. And Twitter/Facebook/etc will show a rich content on their timelines.
https://bugzilla.wikimedia.org/showdependencytree.cgi?id=54829&hide_reso... tracks this. Bug 30113 has a small patch attached, if you want to give a look.
Nemo
Hi Mingli, may I suggest that you post some of your interesting thoughts in IdeaLab so that others can work with them and build on them?
https://meta.wikimedia.org/wiki/Idealab
Pine
On Tue, Jul 1, 2014 at 1:42 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Thanks for the addendum. :-)
Mingli Yuan, 01/07/2014 08:44:
The content provider label their own content with some metadata. And Twitter/Facebook/etc will show a rich content on their timelines.
https://bugzilla.wikimedia.org/showdependencytree.cgi?id=54829&hide_reso... tracks this. Bug 30113 has a small patch attached, if you want to give a look.
Nemo
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
I am really so glad to see your post, Mingli. I hope you are well :--)
Yes, this idea of observability is great. RecentChanges was a real strength of early wikis. Now we have so much metadata about pages and edits, we could cluster results in a more meaningful way...
Also: what other ideas from the early development of collaborative tools are useful to revisit? Perhaps we can get some of the early c2 folks to come join this thread.
- filtering up information to the 'top' view on a page. (timestamps of last changes, or the list of editors, or annotations visible directly on the page you are reading)
- rich collapsible outline views (readable, with thumbnails and topic sentences, and multiple collapse levels; not separated into a redundant TOC) + Hackpad does a very little bit of this
- barnraisings for new projects, explicit places to interconnect two wikis with different communities (that might otherwise not communicate) + One parallel today: making use of our banners to share messages to every one reading or editing a specific category, to let them know about something happening elsewhere 'in that category'
Sam
On Thu, Jun 5, 2014 at 1:43 PM, Mingli Yuan mingli.yuan@gmail.com wrote:
Hi, folks,
Recently Lila had talk about #1 challenge in this mail-list which is related to participation. I want to recall Ward Cunningham's idea of observability in the very early days of wiki invention to address the possibility to enhance participation of Wikipedia today.
If you visit the early page of c2.com, you will find the idea of observability is one pillar principle of wiki software, and just follow the idea, Ward invent the RecentChanges for all wikis.
At that time c2 is very small; now Wikipedia is so big. The original idea of RecentChanges is not very effective today. We had made some extension for the original idea in our mediawiki software, but I think the step is too small.
Let's first take a look of what we had already invented are similar to RecentChanges but more effective:
- Wikizine or Signpost: community stories every week
- some part of a Portal: recent changes under a subject compiled by human
Still possible for other kind of RecentChanges which is not invented yet, for example:
- References and external links are very valuable resources, why not
extract them from articles and compile them into a timeline?
Content is only one aspect to observe, people are another:
- Who are the experts on some topics?
- Who are my buddies on some articles?
- Who did help me to improve an article originally I wrote?
In all, we may reshape our technical infrastructure in this direction for new spaces of participation. And finally, one open question for the system designer:
- Towards better content and community, what is the most important things
we want our user to observe?
Regards, Mingli _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Mingli Yuan, 05/06/2014 19:43:
If you visit the early page of c2.com, you will find the idea of observability is one pillar principle of wiki software, and just follow the idea, Ward invent the RecentChanges for all wikis.
Can you please find that specific page/formulation of the principle? I'd like to reference it from point 1 of https://www.mediawiki.org/wiki/Principles but I couldn't find it with a quick search. (Note, it's not really *universally* accepted as a wiki principle.)
Some rather big software development projects have failed, recently, in ways that a simple checklist like the page above could have avoided. So this is an important conversation to have.
At that time c2 is very small; now Wikipedia is so big. The original idea of RecentChanges is not very effective today.
Nor in 2002. :) http://c2.com/cgi/wiki?TooManyRecentChanges
We had made some extension for the original idea in our mediawiki software, but I think the step is too small.
Let's first take a look of what we had already invented are similar to RecentChanges but more effective:
- Wikizine or Signpost: community stories every week
- some part of a Portal: recent changes under a subject compiled by human
Still possible for other kind of RecentChanges which is not invented yet, for example:
- References and external links are very valuable resources, why not
extract them from articles and compile them into a timeline?
None of these escapes http://c2.com/cgi/wiki?RecentChangesIsNotTheWiki ; some have failed before: http://meatballwiki.org/wiki/RoleOfRecentChanges
Content is only one aspect to observe, people are another:
Attention, we're radically rooted in http://meatballwiki.org/wiki/ContentOverCommunity
- Who are the experts on some topics?
- Who are my buddies on some articles?
- Who did help me to improve an article originally I wrote?
In all, we may reshape our technical infrastructure in this direction for new spaces of participation. And finally, one open question for the system designer:
- Towards better content and community, what is the most important things
we want our user to observe?
I'm not sure that's the right question. Anyway, more reading: http://meatballwiki.org/wiki/back=CategoryRecentChanges http://c2.com/cgi/wiki?search=RecentChanges
Nemo
Hi, Nemo,
Can you please find that specific page/formulation of the principle?
I'd like to reference it from point 1 of https://www.mediawiki.org/ wiki/Principles but I couldn't find it with a quick search. (Note, it's not really *universally* accepted as a wiki principle.)
It is at http://c2.com/cgi/wiki?WikiDesignPrinciples
Hi, Samuel,
Now we have so much metadata about pages and edits, we could cluster
results in a more meaningful way...
Yes! If Summly can help people read news, why not to observe wiki in a more meaningful way?
https://en.wikipedia.org/wiki/Nick_D%27Aloisio
On Fri, Jun 6, 2014 at 2:31 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Mingli Yuan, 05/06/2014 19:43:
If you visit the early page of c2.com, you will find the idea
of observability is one pillar principle of wiki software, and just follow the idea, Ward invent the RecentChanges for all wikis.
Can you please find that specific page/formulation of the principle? I'd like to reference it from point 1 of https://www.mediawiki.org/ wiki/Principles but I couldn't find it with a quick search. (Note, it's not really *universally* accepted as a wiki principle.)
Some rather big software development projects have failed, recently, in ways that a simple checklist like the page above could have avoided. So this is an important conversation to have.
At that time c2 is very small; now Wikipedia is so big. The original idea of RecentChanges is not very effective today.
Nor in 2002. :) http://c2.com/cgi/wiki?TooManyRecentChanges
We had made some extension
for the original idea in our mediawiki software, but I think the step is too small.
Let's first take a look of what we had already invented are similar to RecentChanges but more effective:
- Wikizine or Signpost: community stories every week
- some part of a Portal: recent changes under a subject compiled by human
Still possible for other kind of RecentChanges which is not invented yet, for example:
- References and external links are very valuable resources, why not
extract them from articles and compile them into a timeline?
None of these escapes http://c2.com/cgi/wiki?RecentChangesIsNotTheWiki ; some have failed before: http://meatballwiki.org/wiki/RoleOfRecentChanges
Content is only one aspect to observe, people are another:
Attention, we're radically rooted in http://meatballwiki.org/wiki/ ContentOverCommunity
- Who are the experts on some topics?
- Who are my buddies on some articles?
- Who did help me to improve an article originally I wrote?
In all, we may reshape our technical infrastructure in this direction for new spaces of participation. And finally, one open question for the system designer:
- Towards better content and community, what is the most important things
we want our user to observe?
I'm not sure that's the right question. Anyway, more reading: http://meatballwiki.org/wiki/back=CategoryRecentChanges http://c2.com/cgi/wiki?search=RecentChanges
Nemo
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
One small step forward might be to add more support to 'groups' in the mediawiki codebase. Groups could help organize the various subcommunities. Perhaps consider this a federal system for wikipedia. ;)
I have been experimenting with real-time collaborative editors on wikipedia. One question that arises is: how do I find others who are interested in working on this particular page with me? Currently there are a number of ad-hoc methods used.
One could imagine that the participants on a particular article's talk page consistute a sort of ad hoc "group". Various wikiprojects are a more formal group. But can we think about this more, and come up with better mediawiki tools to find/discover/join/share/discuss things in our group(s)? --scott
On Thu, Jun 5, 2014 at 2:57 PM, Mingli Yuan mingli.yuan@gmail.com wrote:
Hi, Nemo,
Can you please find that specific page/formulation of the principle?
I'd like to reference it from point 1 of https://www.mediawiki.org/ wiki/Principles but I couldn't find it with a quick search. (Note, it's not really *universally* accepted as a wiki principle.)
It is at http://c2.com/cgi/wiki?WikiDesignPrinciples
Hi, Samuel,
Now we have so much metadata about pages and edits, we could cluster
results in a more meaningful way...
Yes! If Summly can help people read news, why not to observe wiki in a more meaningful way?
https://en.wikipedia.org/wiki/Nick_D%27Aloisio
On Fri, Jun 6, 2014 at 2:31 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Mingli Yuan, 05/06/2014 19:43:
If you visit the early page of c2.com, you will find the idea
of observability is one pillar principle of wiki software, and just
follow
the idea, Ward invent the RecentChanges for all wikis.
Can you please find that specific page/formulation of the principle? I'd like to reference it from point 1 of https://www.mediawiki.org/ wiki/Principles but I couldn't find it with a quick search. (Note, it's not really *universally* accepted as a wiki principle.)
Some rather big software development projects have failed, recently, in ways that a simple checklist like the page above could have avoided. So this is an important conversation to have.
At that time c2 is very small; now Wikipedia is so big. The original
idea
of RecentChanges is not very effective today.
Nor in 2002. :) http://c2.com/cgi/wiki?TooManyRecentChanges
We had made some extension
for the original idea in our mediawiki software, but I think the step is too small.
Let's first take a look of what we had already invented are similar to RecentChanges but more effective:
- Wikizine or Signpost: community stories every week
- some part of a Portal: recent changes under a subject compiled by
human
Still possible for other kind of RecentChanges which is not invented
yet,
for example:
- References and external links are very valuable resources, why not
extract them from articles and compile them into a timeline?
None of these escapes http://c2.com/cgi/wiki?RecentChangesIsNotTheWiki ; some have failed before:
http://meatballwiki.org/wiki/RoleOfRecentChanges
Content is only one aspect to observe, people are another:
Attention, we're radically rooted in http://meatballwiki.org/wiki/ ContentOverCommunity
- Who are the experts on some topics?
- Who are my buddies on some articles?
- Who did help me to improve an article originally I wrote?
In all, we may reshape our technical infrastructure in this direction
for
new spaces of participation. And finally, one open question for the
system
designer:
- Towards better content and community, what is the most important
things
we want our user to observe?
I'm not sure that's the right question. Anyway, more reading: http://meatballwiki.org/wiki/back=CategoryRecentChanges http://c2.com/cgi/wiki?search=RecentChanges
Nemo
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
You could start by listing the ad hoc methods. Others might add to the list. The list might inspire alternative ideas. Cheers, Peter
-----Original Message----- From: wikimedia-l-bounces@lists.wikimedia.org [mailto:wikimedia-l-bounces@lists.wikimedia.org] On Behalf Of C. Scott Ananian Sent: 06 June 2014 04:54 PM To: Wikimedia Mailing List Subject: Re: [Wikimedia-l] Rethink of observability
One small step forward might be to add more support to 'groups' in the mediawiki codebase. Groups could help organize the various subcommunities. Perhaps consider this a federal system for wikipedia. ;)
I have been experimenting with real-time collaborative editors on wikipedia. One question that arises is: how do I find others who are interested in working on this particular page with me? Currently there are a number of ad-hoc methods used.
One could imagine that the participants on a particular article's talk page consistute a sort of ad hoc "group". Various wikiprojects are a more formal group. But can we think about this more, and come up with better mediawiki tools to find/discover/join/share/discuss things in our group(s)? --scott
On Thu, Jun 5, 2014 at 2:57 PM, Mingli Yuan mingli.yuan@gmail.com wrote:
Hi, Nemo,
Can you please find that specific page/formulation of the principle?
I'd like to reference it from point 1 of https://www.mediawiki.org/ wiki/Principles but I couldn't find it with a quick search. (Note, it's not really *universally* accepted as a wiki principle.)
It is at http://c2.com/cgi/wiki?WikiDesignPrinciples
Hi, Samuel,
Now we have so much metadata about pages and edits, we could cluster
results in a more meaningful way...
Yes! If Summly can help people read news, why not to observe wiki in a more meaningful way?
https://en.wikipedia.org/wiki/Nick_D%27Aloisio
On Fri, Jun 6, 2014 at 2:31 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Mingli Yuan, 05/06/2014 19:43:
If you visit the early page of c2.com, you will find the idea
of observability is one pillar principle of wiki software, and just
follow
the idea, Ward invent the RecentChanges for all wikis.
Can you please find that specific page/formulation of the principle? I'd like to reference it from point 1 of https://www.mediawiki.org/ wiki/Principles but I couldn't find it with a quick search. (Note, it's not really *universally* accepted as a wiki principle.)
Some rather big software development projects have failed, recently, in ways that a simple checklist like the page above could have avoided. So this is an important conversation to have.
At that time c2 is very small; now Wikipedia is so big. The original
idea
of RecentChanges is not very effective today.
Nor in 2002. :) http://c2.com/cgi/wiki?TooManyRecentChanges
We had made some extension
for the original idea in our mediawiki software, but I think the step is too small.
Let's first take a look of what we had already invented are similar to RecentChanges but more effective:
- Wikizine or Signpost: community stories every week
- some part of a Portal: recent changes under a subject compiled by
human
Still possible for other kind of RecentChanges which is not invented
yet,
for example:
- References and external links are very valuable resources, why
not extract them from articles and compile them into a timeline?
None of these escapes http://c2.com/cgi/wiki?RecentChangesIsNotTheWiki ; some have failed before:
http://meatballwiki.org/wiki/RoleOfRecentChanges
Content is only one aspect to observe, people are another:
Attention, we're radically rooted in http://meatballwiki.org/wiki/ ContentOverCommunity
- Who are the experts on some topics?
- Who are my buddies on some articles?
- Who did help me to improve an article originally I wrote?
In all, we may reshape our technical infrastructure in this direction
for
new spaces of participation. And finally, one open question for the
system
designer:
- Towards better content and community, what is the most important
things
we want our user to observe?
I'm not sure that's the right question. Anyway, more reading: http://meatballwiki.org/wiki/back=CategoryRecentChanges http://c2.com/cgi/wiki?search=RecentChanges
Nemo
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- (http://cscott.net) _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4592 / Virus Database: 3955/7629 - Release Date: 06/05/14
You could start by listing the ad hoc methods. Others might add to the
list.
The list might inspire alternative ideas. --scott
Yes, Scott. We should do that.
Collect what we had invented or some interesting new ideas, and then try to reorganize them into an order, in such a way, we can reshape our old space to a new form. We need a brainstorming.
Before go to details, I what to talk something about Christopher Alexander, design pattern, and their relationship to wiki, and then back to observability.
I was only a young programmer when I personally got to know design pattern and Christopher Alexander about ten years ago. At that time, I think design pattern was only a solution to a frequent problem. Several years later, I had read the books '''The Oregon Experiment''' and some part of '''The Timeless Way of Building''', I began to realize pattern is only a methodology for making an organic ( or live, harmonic, etc) environment by a group of people in a self-organized way.
It looks to be occasional that Ward Cunningham invented WikiWikiWeb for collecting design patterns in OO programming. But I think the real relationship between wiki and design pattern are deep.
Because we can trace some essential ideas of modern Wiki practice back to the ideas of Christopher Alexander.
Consensus in wiki vs. participation of a building process by everyone in a community
Accumulate small anarchy contributions into an ordered form vs. The slowly growth of town in an organic way
etc.
Why talk about these, because modern Wiki world is like a big city. If we want to reshape the city, we should take a look at what architect says.
Let's back to observability. Why observability is important? Because we are recognizing our environment from our observation, and all consequent events are based on the observation.
While what can be observed is a choice of the designer.
Regards, Mingli
wikimedia-l@lists.wikimedia.org