I am writing to invite you to preview and hopefully contribute to Gather [1], a new MediaWiki extension that allows users to create, share, and discover lists of articles. Gather is currently available for all users of the mobile site who have opted in to beta. This launch was primarily for the community to test it and to pardon the pun... gather... some data. We would love for you to try it out and share your feedback with us.
The best way to explain what Gather lists are is to contrast them with existing facilities for grouping articles: categories and list articles. Categories and list articles exist in subject namespaces, and their goal is to provide navigational links for articles whose subjects share some common, defining property. Gather lists have a similar goal of facilitating content discovery but differ in that they allow users the ability to group articles on the basis of any criterion, whether this be overtly subjective and irreverent ("articles I enjoy"); curated on the basis of cultivated tastes and informed opinions ("the most groundbreaking discoveries in chemistry"); educational at a more localised level ("Pages that Mr Robson's A-level chemistry students should read") or simply a personal todo list ("articles i want to edit/read today").
The Gather lists you create are currently your own [A] and you decide whether or not they are visible to others [B]. To see some example lists check out: https://en.m.wikipedia.org/wiki/Special:Gather/by/Jdlrobson/23 https://en.m.wikipedia.org/wiki/Special:Gather/by/Jdlrobson/35 https://en.m.wikipedia.org/wiki/Special:Gather/by/Sonasonic/71
If you want to have a go at making your own lists you have two options (both require a mediawiki account): 1) Opt in to mobile site beta: https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions&retur... and then interact with the watchstar 2) Try it out on Vector [C]: https://en.m.wikipedia.org/wiki/User:Jdlrobson/vector.js
To build this we have looked at the existing watchlist code, the Collections extension, the multiple lists in core RFC and the many feature requests around watchlist that span the lifetime of this project. Apologies in advance for lack of documentation, sometimes talking and back and forth over IRC/coffee is more productive then writing extensive documentation, but I promise you the team has been listening to all sorts of use cases.
As a result I think now we have the first essential building block - the ability for a user to store and access a structured public or private list.
We have APIs that will allow you to: * create new lists that are private or public * edit lists * add and remove pages to those lists * query lists * moderators to hide troublesome lists * manipulate the watchlist which has special handling to turn it into a collection
Next up on the immediate roadmap for those that are interested: * Fixing up API bugs, missing documentation * Pagination was sorely missing from the first release. Code for that has merged so that's coming soon. * Polishing the existing user experience and working out how to port that to desktop * Improving on moderation tools * The ability for multiple users to share and manage a list * Combining the data inside a list with other data e.g. recent changes to make multiple watchlists. I have a first version of this patch ready for review [3] and working towards the goal of public/private watchlists [4].
We have a long way to go and I guess this is the main reason I'm writing this mail - I'm hoping to collect more help from across our community.
If you are interested in helping feel free to reach out to me off list on irc (user jdlrobson) or poke around Phabricator [5].
Thanks for the read! Jon
[1] https://www.mediawiki.org/wiki/Extension:Gather [2] http://en.wikipedia.beta.wmflabs.org/w/api.php?action=help&modules=editl... [3] https://gerrit.wikimedia.org/r/#/c/200181/ [4] https://phabricator.wikimedia.org/T9467 [5] https://phabricator.wikimedia.org/tag/gather/
[A] In the future we would love to support collaborative editing of collections. Any one interested in helping? [B] ... Although currently the UI only supports public lists... API supports both. Help us build that out. [C] Highly experimental - this is still a WIP and may have lots of kinks. I would love a volunteer full time to help me with the desktop experience. It should be noted that the Gather extension works on desktop, but we've de-scoped the work there whilst UX standardisation is ongoing and to limit the workload so we can actually get things done quickly. There is currently a dependency on MobileFrontend for convenience but we hope to drop that very soon (https://phabricator.wikimedia.org/T94100). [D] (albeit badly documented - patches welcomed!
Hi Jon,
You might want to discuss this project here: https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Council
You could also discuss this with the WikiProject X team: https://en.wikipedia.org/wiki/Wikipedia:WikiProject_X
Pine
*This is an Encyclopedia* https://www.wikipedia.org/
*One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.*
*—Catherine Munro*
On Thu, Apr 2, 2015 at 3:19 PM, Jon Robson jrobson@wikimedia.org wrote:
I am writing to invite you to preview and hopefully contribute to Gather [1], a new MediaWiki extension that allows users to create, share, and discover lists of articles. Gather is currently available for all users of the mobile site who have opted in to beta. This launch was primarily for the community to test it and to pardon the pun... gather... some data. We would love for you to try it out and share your feedback with us.
The best way to explain what Gather lists are is to contrast them with existing facilities for grouping articles: categories and list articles. Categories and list articles exist in subject namespaces, and their goal is to provide navigational links for articles whose subjects share some common, defining property. Gather lists have a similar goal of facilitating content discovery but differ in that they allow users the ability to group articles on the basis of any criterion, whether this be overtly subjective and irreverent ("articles I enjoy"); curated on the basis of cultivated tastes and informed opinions ("the most groundbreaking discoveries in chemistry"); educational at a more localised level ("Pages that Mr Robson's A-level chemistry students should read") or simply a personal todo list ("articles i want to edit/read today").
The Gather lists you create are currently your own [A] and you decide whether or not they are visible to others [B]. To see some example lists check out: https://en.m.wikipedia.org/wiki/Special:Gather/by/Jdlrobson/23 https://en.m.wikipedia.org/wiki/Special:Gather/by/Jdlrobson/35 https://en.m.wikipedia.org/wiki/Special:Gather/by/Sonasonic/71
If you want to have a go at making your own lists you have two options (both require a mediawiki account):
- Opt in to mobile site beta:
https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions&retur... and then interact with the watchstar 2) Try it out on Vector [C]: https://en.m.wikipedia.org/wiki/User:Jdlrobson/vector.js
To build this we have looked at the existing watchlist code, the Collections extension, the multiple lists in core RFC and the many feature requests around watchlist that span the lifetime of this project. Apologies in advance for lack of documentation, sometimes talking and back and forth over IRC/coffee is more productive then writing extensive documentation, but I promise you the team has been listening to all sorts of use cases.
As a result I think now we have the first essential building block - the ability for a user to store and access a structured public or private list.
We have APIs that will allow you to:
- create new lists that are private or public
- edit lists
- add and remove pages to those lists
- query lists
- moderators to hide troublesome lists
- manipulate the watchlist which has special handling to turn it into
a collection
Next up on the immediate roadmap for those that are interested:
- Fixing up API bugs, missing documentation
- Pagination was sorely missing from the first release. Code for that
has merged so that's coming soon.
- Polishing the existing user experience and working out how to port
that to desktop
- Improving on moderation tools
- The ability for multiple users to share and manage a list
- Combining the data inside a list with other data e.g. recent changes
to make multiple watchlists. I have a first version of this patch ready for review [3] and working towards the goal of public/private watchlists [4].
We have a long way to go and I guess this is the main reason I'm writing this mail - I'm hoping to collect more help from across our community.
If you are interested in helping feel free to reach out to me off list on irc (user jdlrobson) or poke around Phabricator [5].
Thanks for the read! Jon
[1] https://www.mediawiki.org/wiki/Extension:Gather [2] http://en.wikipedia.beta.wmflabs.org/w/api.php?action=help&modules=editl... [3] https://gerrit.wikimedia.org/r/#/c/200181/ [4] https://phabricator.wikimedia.org/T9467 [5] https://phabricator.wikimedia.org/tag/gather/
[A] In the future we would love to support collaborative editing of collections. Any one interested in helping? [B] ... Although currently the UI only supports public lists... API supports both. Help us build that out. [C] Highly experimental - this is still a WIP and may have lots of kinks. I would love a volunteer full time to help me with the desktop experience. It should be noted that the Gather extension works on desktop, but we've de-scoped the work there whilst UX standardisation is ongoing and to limit the workload so we can actually get things done quickly. There is currently a dependency on MobileFrontend for convenience but we hope to drop that very soon (https://phabricator.wikimedia.org/T94100). [D] (albeit badly documented - patches welcomed!
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Jon -
These look interesting, and I'm sure some people will enjoy them a lot.
From my perspective as a oversighter and checkuser, as long as I'm able to
suppress information on the page, and the "edits" to the page show up in the contributions tables that are available for checkusers for review, I'm perfectly fine with these "pages". (Note - I've already thought of multiple reasons that we'd wind up needing to suppress information on these pages, not to mention half a dozen ways that the pages could be used inappropriately that could lead to checkusering -- just like any other page on Wikipedia. They don't need a different level of scrutiny, just the same level as everywhere else.) Admins being able to delete the page isn't enough, so please ensure that these are fully tested. I'll be happy to work with you on that.
On the other hand, I think it would be a net positive if everyone stops calling these pages "lists". Lists are a specific type of content that has existed on Wikipedia practically since its inception; projects have guidelines and sometimes even policies on their creation, use and format. Thousands of users have had their own personal lists in their userspace for pretty much the entire history of the project, too. Thus, the subject line of this thread is inaccurate: Lists have pretty much always been first class citizens on Wikipedia projects. This new extension does not create lists in the Wikipedia sense, it creates a collection of article thumbnails. Calling these new "pages" lists as well, even if just talking in the vernacular, will be confusing.
So...please give some further thought to what to call these pages that doesn't use a term that is already well-understood to mean something entirely different. From my perspective, the idea (and the execution) is fine.
RIsker/Anne
On 2 April 2015 at 18:19, Jon Robson jrobson@wikimedia.org wrote:
I am writing to invite you to preview and hopefully contribute to Gather [1], a new MediaWiki extension that allows users to create, share, and discover lists of articles. Gather is currently available for all users of the mobile site who have opted in to beta. This launch was primarily for the community to test it and to pardon the pun... gather... some data. We would love for you to try it out and share your feedback with us.
The best way to explain what Gather lists are is to contrast them with existing facilities for grouping articles: categories and list articles. Categories and list articles exist in subject namespaces, and their goal is to provide navigational links for articles whose subjects share some common, defining property. Gather lists have a similar goal of facilitating content discovery but differ in that they allow users the ability to group articles on the basis of any criterion, whether this be overtly subjective and irreverent ("articles I enjoy"); curated on the basis of cultivated tastes and informed opinions ("the most groundbreaking discoveries in chemistry"); educational at a more localised level ("Pages that Mr Robson's A-level chemistry students should read") or simply a personal todo list ("articles i want to edit/read today").
The Gather lists you create are currently your own [A] and you decide whether or not they are visible to others [B]. To see some example lists check out: https://en.m.wikipedia.org/wiki/Special:Gather/by/Jdlrobson/23 https://en.m.wikipedia.org/wiki/Special:Gather/by/Jdlrobson/35 https://en.m.wikipedia.org/wiki/Special:Gather/by/Sonasonic/71
If you want to have a go at making your own lists you have two options (both require a mediawiki account):
- Opt in to mobile site beta:
https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions&retur... and then interact with the watchstar 2) Try it out on Vector [C]: https://en.m.wikipedia.org/wiki/User:Jdlrobson/vector.js
To build this we have looked at the existing watchlist code, the Collections extension, the multiple lists in core RFC and the many feature requests around watchlist that span the lifetime of this project. Apologies in advance for lack of documentation, sometimes talking and back and forth over IRC/coffee is more productive then writing extensive documentation, but I promise you the team has been listening to all sorts of use cases.
As a result I think now we have the first essential building block - the ability for a user to store and access a structured public or private list.
We have APIs that will allow you to:
- create new lists that are private or public
- edit lists
- add and remove pages to those lists
- query lists
- moderators to hide troublesome lists
- manipulate the watchlist which has special handling to turn it into
a collection
Next up on the immediate roadmap for those that are interested:
- Fixing up API bugs, missing documentation
- Pagination was sorely missing from the first release. Code for that
has merged so that's coming soon.
- Polishing the existing user experience and working out how to port
that to desktop
- Improving on moderation tools
- The ability for multiple users to share and manage a list
- Combining the data inside a list with other data e.g. recent changes
to make multiple watchlists. I have a first version of this patch ready for review [3] and working towards the goal of public/private watchlists [4].
We have a long way to go and I guess this is the main reason I'm writing this mail - I'm hoping to collect more help from across our community.
If you are interested in helping feel free to reach out to me off list on irc (user jdlrobson) or poke around Phabricator [5].
Thanks for the read! Jon
[1] https://www.mediawiki.org/wiki/Extension:Gather [2] http://en.wikipedia.beta.wmflabs.org/w/api.php?action=help&modules=editl... [3] https://gerrit.wikimedia.org/r/#/c/200181/ [4] https://phabricator.wikimedia.org/T9467 [5] https://phabricator.wikimedia.org/tag/gather/
[A] In the future we would love to support collaborative editing of collections. Any one interested in helping? [B] ... Although currently the UI only supports public lists... API supports both. Help us build that out. [C] Highly experimental - this is still a WIP and may have lots of kinks. I would love a volunteer full time to help me with the desktop experience. It should be noted that the Gather extension works on desktop, but we've de-scoped the work there whilst UX standardisation is ongoing and to limit the workload so we can actually get things done quickly. There is currently a dependency on MobileFrontend for convenience but we hope to drop that very soon (https://phabricator.wikimedia.org/T94100). [D] (albeit badly documented - patches welcomed!
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I hereby nominate "collections". Describes it well and, at least to my ear, helps convey a bit of the notion that it's a personal thing. KWW
Risker schreef op 2015/04/04 om 8:08:
Hi Jon -
These look interesting, and I'm sure some people will enjoy them a lot. From my perspective as a oversighter and checkuser, as long as I'm able to suppress information on the page, and the "edits" to the page show up in the contributions tables that are available for checkusers for review, I'm perfectly fine with these "pages". (Note - I've already thought of multiple reasons that we'd wind up needing to suppress information on these pages, not to mention half a dozen ways that the pages could be used inappropriately that could lead to checkusering -- just like any other page on Wikipedia. They don't need a different level of scrutiny, just the same level as everywhere else.) Admins being able to delete the page isn't enough, so please ensure that these are fully tested. I'll be happy to work with you on that.
On the other hand, I think it would be a net positive if everyone stops calling these pages "lists". Lists are a specific type of content that has existed on Wikipedia practically since its inception; projects have guidelines and sometimes even policies on their creation, use and format. Thousands of users have had their own personal lists in their userspace for pretty much the entire history of the project, too. Thus, the subject line of this thread is inaccurate: Lists have pretty much always been first class citizens on Wikipedia projects. This new extension does not create lists in the Wikipedia sense, it creates a collection of article thumbnails. Calling these new "pages" lists as well, even if just talking in the vernacular, will be confusing.
So...please give some further thought to what to call these pages that doesn't use a term that is already well-understood to mean something entirely different. From my perspective, the idea (and the execution) is fine.
RIsker/Anne
Collections are already taken as well: https://www.mediawiki.org/wiki/Extension:Collection
On 4 April 2015 at 16:15, Kevin Wayne Williams kwwilliams@kwwilliams.com wrote:
I hereby nominate "collections". Describes it well and, at least to my ear, helps convey a bit of the notion that it's a personal thing. KWW
Risker schreef op 2015/04/04 om 8:08:
Hi Jon -
These look interesting, and I'm sure some people will enjoy them a lot. From my perspective as a oversighter and checkuser, as long as I'm able to suppress information on the page, and the "edits" to the page show up in the contributions tables that are available for checkusers for review, I'm perfectly fine with these "pages". (Note - I've already thought of multiple reasons that we'd wind up needing to suppress information on these pages, not to mention half a dozen ways that the pages could be used inappropriately that could lead to checkusering -- just like any other page on Wikipedia. They don't need a different level of scrutiny, just the same level as everywhere else.) Admins being able to delete the page isn't enough, so please ensure that these are fully tested. I'll be happy to work with you on that.
On the other hand, I think it would be a net positive if everyone stops calling these pages "lists". Lists are a specific type of content that has existed on Wikipedia practically since its inception; projects have guidelines and sometimes even policies on their creation, use and format. Thousands of users have had their own personal lists in their userspace for pretty much the entire history of the project, too. Thus, the subject line of this thread is inaccurate: Lists have pretty much always been first class citizens on Wikipedia projects. This new extension does not create lists in the Wikipedia sense, it creates a collection of article thumbnails. Calling these new "pages" lists as well, even if just talking in the vernacular, will be confusing.
So...please give some further thought to what to call these pages that doesn't use a term that is already well-understood to mean something entirely different. From my perspective, the idea (and the execution) is fine.
RIsker/Anne
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Oh look, we go full circle ;)
----
I haven't checked but given its implemented as a special page i doubt Risker's cu concerns are addressed. Edits to lists do not appear in contribs on beta site.
--bawolff
On Apr 4, 2015 11:15 AM, "Kevin Wayne Williams" kwwilliams@kwwilliams.com wrote:
I hereby nominate "collections". Describes it well and, at least to my
ear, helps convey a bit of the notion that it's a personal thing.
KWW
Risker schreef op 2015/04/04 om 8:08:
Hi Jon -
These look interesting, and I'm sure some people will enjoy them a lot. From my perspective as a oversighter and checkuser, as long as I'm able
to
suppress information on the page, and the "edits" to the page show up in the contributions tables that are available for checkusers for review,
I'm
perfectly fine with these "pages". (Note - I've already thought of multiple reasons that we'd wind up needing to suppress information on
these
pages, not to mention half a dozen ways that the pages could be used inappropriately that could lead to checkusering -- just like any other
page
on Wikipedia. They don't need a different level of scrutiny, just the
same
level as everywhere else.) Admins being able to delete the page isn't enough, so please ensure that these are fully tested. I'll be happy to work with you on that.
On the other hand, I think it would be a net positive if everyone stops calling these pages "lists". Lists are a specific type of content that
has
existed on Wikipedia practically since its inception; projects have guidelines and sometimes even policies on their creation, use and format. Thousands of users have had their own personal lists in their userspace
for
pretty much the entire history of the project, too. Thus, the subject
line
of this thread is inaccurate: Lists have pretty much always been first class citizens on Wikipedia projects. This new extension does not create lists in the Wikipedia sense, it creates a collection of article thumbnails. Calling these new "pages" lists as well, even if just
talking
in the vernacular, will be confusing.
So...please give some further thought to what to call these pages that doesn't use a term that is already well-understood to mean something entirely different. From my perspective, the idea (and the execution) is fine.
RIsker/Anne
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Indeed. What about "Gathering" (which at least matches the name of the extension) or "Cluster" - maybe even "Compilation". Of course, there's the problem of having two extensions doing similar things, which will create problems when we have to come up with words in other languages, too.
Nonetheless, those are some suggestions for English.
Risker/Anne
On 4 April 2015 at 12:37, Brian Wolff bawolff@gmail.com wrote:
Oh look, we go full circle ;)
I haven't checked but given its implemented as a special page i doubt Risker's cu concerns are addressed. Edits to lists do not appear in contribs on beta site.
--bawolff
On Apr 4, 2015 11:15 AM, "Kevin Wayne Williams" <kwwilliams@kwwilliams.com
wrote:
I hereby nominate "collections". Describes it well and, at least to my
ear, helps convey a bit of the notion that it's a personal thing.
KWW
Risker schreef op 2015/04/04 om 8:08:
Hi Jon -
These look interesting, and I'm sure some people will enjoy them a lot. From my perspective as a oversighter and checkuser, as long as I'm able
to
suppress information on the page, and the "edits" to the page show up in the contributions tables that are available for checkusers for review,
I'm
perfectly fine with these "pages". (Note - I've already thought of multiple reasons that we'd wind up needing to suppress information on
these
pages, not to mention half a dozen ways that the pages could be used inappropriately that could lead to checkusering -- just like any other
page
on Wikipedia. They don't need a different level of scrutiny, just the
same
level as everywhere else.) Admins being able to delete the page isn't enough, so please ensure that these are fully tested. I'll be happy to work with you on that.
On the other hand, I think it would be a net positive if everyone stops calling these pages "lists". Lists are a specific type of content that
has
existed on Wikipedia practically since its inception; projects have guidelines and sometimes even policies on their creation, use and
format.
Thousands of users have had their own personal lists in their userspace
for
pretty much the entire history of the project, too. Thus, the subject
line
of this thread is inaccurate: Lists have pretty much always been first class citizens on Wikipedia projects. This new extension does not create lists in the Wikipedia sense, it creates a collection of article thumbnails. Calling these new "pages" lists as well, even if just
talking
in the vernacular, will be confusing.
So...please give some further thought to what to call these pages that doesn't use a term that is already well-understood to mean something entirely different. From my perspective, the idea (and the execution)
is
fine.
RIsker/Anne
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
If public 'lists' were serialised as real pages (true first class citizens) all the usual functions would work, and if they were serialised as wikitext, those pages would look remarkably like existing Collections.
On Sun, 5 Apr 2015 02:37 Brian Wolff bawolff@gmail.com wrote:
Oh look, we go full circle ;)
I haven't checked but given its implemented as a special page i doubt Risker's cu concerns are addressed. Edits to lists do not appear in contribs on beta site.
--bawolff
On Apr 4, 2015 11:15 AM, "Kevin Wayne Williams" <kwwilliams@kwwilliams.com
wrote:
I hereby nominate "collections". Describes it well and, at least to my
ear, helps convey a bit of the notion that it's a personal thing.
KWW
Risker schreef op 2015/04/04 om 8:08:
Hi Jon -
These look interesting, and I'm sure some people will enjoy them a lot. From my perspective as a oversighter and checkuser, as long as I'm able
to
suppress information on the page, and the "edits" to the page show up in the contributions tables that are available for checkusers for review,
I'm
perfectly fine with these "pages". (Note - I've already thought of multiple reasons that we'd wind up needing to suppress information on
these
pages, not to mention half a dozen ways that the pages could be used inappropriately that could lead to checkusering -- just like any other
page
on Wikipedia. They don't need a different level of scrutiny, just the
same
level as everywhere else.) Admins being able to delete the page isn't enough, so please ensure that these are fully tested. I'll be happy to work with you on that.
On the other hand, I think it would be a net positive if everyone stops calling these pages "lists". Lists are a specific type of content that
has
existed on Wikipedia practically since its inception; projects have guidelines and sometimes even policies on their creation, use and
format.
Thousands of users have had their own personal lists in their userspace
for
pretty much the entire history of the project, too. Thus, the subject
line
of this thread is inaccurate: Lists have pretty much always been first class citizens on Wikipedia projects. This new extension does not create lists in the Wikipedia sense, it creates a collection of article thumbnails. Calling these new "pages" lists as well, even if just
talking
in the vernacular, will be confusing.
So...please give some further thought to what to call these pages that doesn't use a term that is already well-understood to mean something entirely different. From my perspective, the idea (and the execution)
is
fine.
RIsker/Anne
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Can we stop pretending that duct tape is the best thing out there ? It’s great as patch-up material and as an arts project you can probably build a house out of it you really tried, but that doesn’t make it a good building material for a 60 story office building.
DJ, Let’s naturalize a few aliens, so we have more first class citizens
On 7 apr. 2015, at 05:04, jayvdb@gmail.com wrote:
If public 'lists' were serialised as real pages (true first class citizens) all the usual functions would work, and if they were serialised as wikitext, those pages would look remarkably like existing Collections.
On Sun, 5 Apr 2015 02:37 Brian Wolff bawolff@gmail.com wrote:
Oh look, we go full circle ;)
I haven't checked but given its implemented as a special page i doubt Risker's cu concerns are addressed. Edits to lists do not appear in contribs on beta site.
--bawolff
On Apr 4, 2015 11:15 AM, "Kevin Wayne Williams" <kwwilliams@kwwilliams.com
wrote:
I hereby nominate "collections". Describes it well and, at least to my
ear, helps convey a bit of the notion that it's a personal thing.
KWW
Risker schreef op 2015/04/04 om 8:08:
Hi Jon -
These look interesting, and I'm sure some people will enjoy them a lot. From my perspective as a oversighter and checkuser, as long as I'm able
to
suppress information on the page, and the "edits" to the page show up in the contributions tables that are available for checkusers for review,
I'm
perfectly fine with these "pages". (Note - I've already thought of multiple reasons that we'd wind up needing to suppress information on
these
pages, not to mention half a dozen ways that the pages could be used inappropriately that could lead to checkusering -- just like any other
page
on Wikipedia. They don't need a different level of scrutiny, just the
same
level as everywhere else.) Admins being able to delete the page isn't enough, so please ensure that these are fully tested. I'll be happy to work with you on that.
On the other hand, I think it would be a net positive if everyone stops calling these pages "lists". Lists are a specific type of content that
has
existed on Wikipedia practically since its inception; projects have guidelines and sometimes even policies on their creation, use and
format.
Thousands of users have had their own personal lists in their userspace
for
pretty much the entire history of the project, too. Thus, the subject
line
of this thread is inaccurate: Lists have pretty much always been first class citizens on Wikipedia projects. This new extension does not create lists in the Wikipedia sense, it creates a collection of article thumbnails. Calling these new "pages" lists as well, even if just
talking
in the vernacular, will be confusing.
So...please give some further thought to what to call these pages that doesn't use a term that is already well-understood to mean something entirely different. From my perspective, the idea (and the execution)
is
fine.
RIsker/Anne
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I hope no 60 storey building is in the making. The bazaar is horizontal, a vertical suk is too similar to a cathedral.
Nemo
The main motivation for lists as not being wikipages is so that they can be combined with the recent changes feed and other things stored in the database. We'll also hoping to support the filtering of collections via tags which becomes much easier if stored in a database. A watchlist is not a wikipage, so that in my eyes sets a precedent.
We have plenty of options to surface edits to collections as items in the recent changes if necessary. It would be most helpful to articulate what the problems are, rather than say "wikipages are the solution!" This might prove to be true but without understanding the inadequacies of the current approach we won't be able to pass that judgement.. so please test and provide that feedback and we'll find the right solutions.
Thanks for your feedback thus far.
On Wed, Apr 8, 2015 at 8:52 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
I hope no 60 storey building is in the making. The bazaar is horizontal, a vertical suk is too similar to a cathedral.
Nemo
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Well, let's be honest. Whatever the theories behind it, these are content pages, they aren't mini-watchlists or really anything even all that technically related to the watchlist wishlist. Content belongs in a content space. Whether it gets its own wikispace, or it uses userspace, is sort of irrelevant. (Actually a more pertinent question might be "why are these being designed for Mobile?" When I looked at the test pages above using a couple of different mobile phones and a tablet, they looked...well, nowhere near as useful or interesting as they look on a desktop.)
Using the Special:namespace for content requires all kinds of jury-rigged code to even to mimic normal functions like full-page deletion and revision-deletion/suppression; in fact, as far as I know, project-level administrators don't have the ability to delete pages in Special:namespace at all. We've had plenty of experience with this issue: page-level deletion is essentially impossible in several modules that have been designed to operate away from the wikipage model (including Flow and AFT), and the "alternative" to revision-deletion/suppression is pretty much jury-rigged, unreliable, and...well, is essentially what is being proposed for Extension:Gather too. In other words, from the perspective of someone who is going to have to deal with these pages once they're created, they don't work very well, and I can't do some of the things I ought to be able to do with them, and no good explanation of why I shouldn't be able to delete them outright or why I shouldn't be able to revision-delete/supress things instead of making do with sort-of-similar tools that aren't written robustly.
Special:namespace has pretty solidly always been the back room and/or engine room of the project; take a look at the list of special pages, and it's obvious that content-specific, user-specific pages do not belong in the same classification as anything else that's there. It simply makes no sense to put it there.
If it is absolutely necessary that properties specific to the Special:namespace be made available to run Extension:Gather, then create a new namespace with the same properties for Gather. If there is some really good, obvious, well-documented reason why this extension absolutely needs those special properties to be workable (and not "it's easier" or "well, maybe we can use this to build something else") then give its own namespace that is devoted to user-generated or personalized "special" pages - but the case hasn't really been made for it, and it creates a lot more work to write robust code for deletion and revdelete/suppress that will operate on those pages, when both of those are covered by well-written, robust, heavily tested and used code now.
I would have thought that having to constantly write new extension-specific code for these basic admin functions would have gotten tiresome for the developers by now.
Risker/Anne
On 8 April 2015 at 13:58, Jon Robson jdlrobson@gmail.com wrote:
The main motivation for lists as not being wikipages is so that they can be combined with the recent changes feed and other things stored in the database. We'll also hoping to support the filtering of collections via tags which becomes much easier if stored in a database. A watchlist is not a wikipage, so that in my eyes sets a precedent.
We have plenty of options to surface edits to collections as items in the recent changes if necessary. It would be most helpful to articulate what the problems are, rather than say "wikipages are the solution!" This might prove to be true but without understanding the inadequacies of the current approach we won't be able to pass that judgement.. so please test and provide that feedback and we'll find the right solutions.
Thanks for your feedback thus far.
On Wed, Apr 8, 2015 at 8:52 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
I hope no 60 storey building is in the making. The bazaar is horizontal,
a
vertical suk is too similar to a cathedral.
Nemo
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jon Robson
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I think the explicit schema will be brilliant when applied to collections, it will facilitate linking tools and more. But would it make sense to represent lists as a wikidata statements, as a compromise between native SQL and wiki pages? We would gain the standard onwiki tools, a data structure that makes lists queryable and richly linkable, and it also becomes easy to add properties for higher-level projects such as distinguishing between Education Program's "list of articles to review" and "list of articles I'm editing".
-Adam
On Wed, Apr 8, 2015 at 10:58 AM, Jon Robson jdlrobson@gmail.com wrote:
The main motivation for lists as not being wikipages is so that they can be combined with the recent changes feed and other things stored in the database. We'll also hoping to support the filtering of collections via tags which becomes much easier if stored in a database. A watchlist is not a wikipage, so that in my eyes sets a precedent.
We have plenty of options to surface edits to collections as items in the recent changes if necessary. It would be most helpful to articulate what the problems are, rather than say "wikipages are the solution!" This might prove to be true but without understanding the inadequacies of the current approach we won't be able to pass that judgement.. so please test and provide that feedback and we'll find the right solutions.
Thanks for your feedback thus far.
On Wed, Apr 8, 2015 at 8:52 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
I hope no 60 storey building is in the making. The bazaar is horizontal,
a
vertical suk is too similar to a cathedral.
Nemo
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jon Robson
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Apr 8, 2015 2:59 PM, "Jon Robson" jdlrobson@gmail.com wrote:
The main motivation for lists as not being wikipages is so that they can be combined with the recent changes feed and other things stored in the database.
To be nitpicky, not only is it possible to combine rc with wikipages, its been supported (and mostly unused) for ages in the form of special:recentchangeslinked. More structured lists could be done with content handler (as with all things there are pros and cons to such an approach).
We'll also hoping to support the filtering of collections via tags which becomes much easier if stored in a database.
"Tags" is another jargon quaigmire in mw land....
Anyways no particular reason why stuff can't be canonically on a wikipage and extracted to db tables (in a similar fashion to link tables). Doing that gives you history, reverting, oversight, collaborative editing, talk pages, etc for free. (But of course im sure that has its own drawbacks)
[Also its important to keep in mind: it is easy to wax poetic on the mailing list about how something ought to be done, much harder to actually do it. So take my comment with the salt appropriate of somebody who hasn't implemented anything nor has any plans to]
A watchlist is not a wikipage, so that in my eyes sets a precedent.
Its also unequivocally private. I think a lot of the conflict here comes from the dual nature of gather as public/private.
I think a closer precedent would be abuse filters, but the system for editing such things is probably much less popular than watchlists.
We have plenty of options to surface edits to collections as items in the recent changes if necessary. It would be most helpful to articulate what the problems are, rather than say "wikipages are the solution!" This might prove to be true but without understanding the inadequacies of the current approach we won't be able to pass that judgement.. so please test and provide that feedback and we'll find the right solutions.
I think the problem is one of integration. People want anything publically editable to be consistent. Earlier in this thread TheDJ made a comparison to building an office tower with duct tape. Well he has a fair point about hacky solutions, to extend the metaphor, nobody wants an office tower built of fifty different materials either, they want a unified building that looks integrated and consistent. Using wiki pages gives integration with all current site features and any future site feautres which don't exist yet, for free.
Thanks for your feedback thus far.
I appreciate that you are taking the feedback in stride. Some of it has been quite harsh, and if it was me, I would probably be pretty defensive at this point.
--bawolff
On Wed, Apr 8, 2015 at 8:52 AM, Federico Leva (Nemo) nemowiki@gmail.com
wrote:
I hope no 60 storey building is in the making. The bazaar is
horizontal, a
vertical suk is too similar to a cathedral.
Nemo
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jon Robson
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, 08 Apr 2015 21:17:44 +0200, Brian Wolff bawolff@gmail.com wrote:
A watchlist is not a wikipage, so that in my eyes sets a precedent.
Its also unequivocally private. I think a lot of the conflict here comes from the dual nature of gather as public/private. I think a closer precedent would be abuse filters, but the system for editing such things is probably much less popular than watchlists.
The system for editing, viewing history and diffs of abuse filters is just barely adequate. It is an improvement over not having a history at all. It doesn't even have edit summaries. Please do not ever use it as a model for anything. :)
On Wed, Apr 8, 2015 at 12:17 PM, Brian Wolff bawolff@gmail.com wrote:
On Apr 8, 2015 2:59 PM, "Jon Robson" jdlrobson@gmail.com wrote:
The main motivation for lists as not being wikipages is so that they can be combined with the recent changes feed and other things stored in the database.
To be nitpicky, not only is it possible to combine rc with wikipages, its been supported (and mostly unused) for ages in the form of special:recentchangeslinked. More structured lists could be done with content handler (as with all things there are pros and cons to such an approach).
but this wouldn't scale for a Watchlist view - which basically does a JOIN on recent changes with the items in that collection. The experimental http://en.wikipedia.beta.wmflabs.org/wiki/Special:GatherEditFeed which provides a multiple watchlist type feature is only possible because it is done in a database. If you believe there is a way to do that, I'd love to see a prototype from you proving me wrong :-).
We'll also hoping to support the filtering of collections via tags which becomes much easier if stored in a database.
"Tags" is another jargon quaigmire in mw land....
Anyways no particular reason why stuff can't be canonically on a wikipage and extracted to db tables (in a similar fashion to link tables). Doing that gives you history, reverting, oversight, collaborative editing, talk pages, etc for free. (But of course im sure that has its own drawbacks)
[Also its important to keep in mind: it is easy to wax poetic on the mailing list about how something ought to be done, much harder to actually do it. So take my comment with the salt appropriate of somebody who hasn't implemented anything nor has any plans to]
A watchlist is not a wikipage, so that in my eyes sets a precedent.
Its also unequivocally private. I think a lot of the conflict here comes from the dual nature of gather as public/private.
True, but given we as a community apparently want truely public watchlists it's time to work out what that looks like :)
I think a closer precedent would be abuse filters, but the system for editing such things is probably much less popular than watchlists.
We have plenty of options to surface edits to collections as items in the recent changes if necessary. It would be most helpful to articulate what the problems are, rather than say "wikipages are the solution!" This might prove to be true but without understanding the inadequacies of the current approach we won't be able to pass that judgement.. so please test and provide that feedback and we'll find the right solutions.
I think the problem is one of integration. People want anything publically editable to be consistent. Earlier in this thread TheDJ made a comparison to building an office tower with duct tape. Well he has a fair point about hacky solutions, to extend the metaphor, nobody wants an office tower built of fifty different materials either, they want a unified building that looks integrated and consistent. Using wiki pages gives integration with all current site features and any future site feautres which don't exist yet, for free.
Agreed, this is definitely an integration problem. I'd like us to generalise our existing site features and make them less like duct tape. There is very little code abstraction which has traditionally made this difficult. I think when we say "this should be a wiki page" we actually mean something different - in that what we are really saying is "this should integrate with recent changes" or this should integrate with X. Identifying those problems will move us forward as we will find solutions to them and build better software. Starting with "it should be a wikipage" is approaching the problem from the wrong direction. This may turn out to be the solution but it's not a good way to write software efficiently.
Thanks for your feedback thus far.
I appreciate that you are taking the feedback in stride. Some of it has been quite harsh, and if it was me, I would probably be pretty defensive at this point.
I truly do want to build the right thing and I really do believe what we have built so far is well architected (but not perfect). I really do encourage you to identify the gaping holes in this infrastructure so these conversations can become actionable and we can go beyond the wikipage.
--bawolff
On Wed, Apr 8, 2015 at 8:52 AM, Federico Leva (Nemo) nemowiki@gmail.com
wrote:
I hope no 60 storey building is in the making. The bazaar is
horizontal, a
vertical suk is too similar to a cathedral.
Nemo
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jon Robson
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
To be nitpicky, not only is it possible to combine rc with wikipages,
its
been supported (and mostly unused) for ages in the form of special:recentchangeslinked. More structured lists could be done with content handler (as with all things there are pros and cons to such an approach).
but this wouldn't scale for a Watchlist view - which basically does a JOIN on recent changes with the items in that collection. The experimental http://en.wikipedia.beta.wmflabs.org/wiki/Special:GatherEditFeed which provides a multiple watchlist type feature is only possible because it is done in a database. If you believe there is a way to do that, I'd love to see a prototype from you proving me wrong :-).
With content handler you can still add random things to the db in your own custom tables, that just functionally depend on the wiki page. Im not suggesting that you parse a page each time you want a list and then merge with rc in php.
A good example of this is special:recentchangeslinked - wikipages have links, links go in pagelinks (or other depending on type) table, special page does inner join + filesort just like watchlist to get recently changed pages.
We'll also hoping to support the filtering of collections via tags which becomes much easier if stored in a database.
"Tags" is another jargon quaigmire in mw land....
Anyways no particular reason why stuff can't be canonically on a
wikipage
and extracted to db tables (in a similar fashion to link tables). Doing that gives you history, reverting, oversight, collaborative editing,
talk
pages, etc for free. (But of course im sure that has its own drawbacks)
[Also its important to keep in mind: it is easy to wax poetic on the mailing list about how something ought to be done, much harder to
actually
do it. So take my comment with the salt appropriate of somebody who
hasn't
implemented anything nor has any plans to]
A watchlist is not a wikipage, so that in my eyes sets a precedent.
Its also unequivocally private. I think a lot of the conflict here comes from the dual nature of gather as public/private.
True, but given we as a community apparently want truely public watchlists it's time to work out what that looks like :)
[..]
Agreed, this is definitely an integration problem. I'd like us to generalise our existing site features and make them less like duct tape. There is very little code abstraction which has traditionally made this difficult. I think when we say "this should be a wiki page" we actually mean something different - in that what we are really saying is "this should integrate with recent changes" or this should integrate with X. Identifying those problems will move us forward as we will find solutions to them and build better software. Starting with "it should be a wikipage" is approaching the problem from the wrong direction. This may turn out to be the solution but it's not a good way to write software efficiently.
Making foo be an instance of X is a good way to solve the problem of make foo behave like x for all properties of x, including those that don't exist yet. (Making interfaces more generic is also obviously good, but when I hear, it should do all the things wiki pages do, I naturally come to the conclusion it should be a wikipage)
So, lets turn this around - what aspects of wiki pages don't you want this to have? In my mind a wiki page has the following properties: *Is editable *contains data of some kind (not neccesarily wikitext) *is viewable (biggest conflict thus far) *integrates with tools for managing content (history, rc, revdel, etc) *has a unique name in a common shared namespace (i mean namespace in the cs sense of the word, not mediawiki sense)
Which property don't you want? Or are there other properties I forgot that you don't want? If not, what is wrong with wiki pages?
--bawolff
Can I just agree with everything Brian just said?
+1 :)
Am 08.04.2015 um 23:50 schrieb Brian Wolff:
To be nitpicky, not only is it possible to combine rc with wikipages,
its
been supported (and mostly unused) for ages in the form of special:recentchangeslinked. More structured lists could be done with content handler (as with all things there are pros and cons to such an approach).
but this wouldn't scale for a Watchlist view - which basically does a JOIN on recent changes with the items in that collection. The experimental http://en.wikipedia.beta.wmflabs.org/wiki/Special:GatherEditFeed which provides a multiple watchlist type feature is only possible because it is done in a database. If you believe there is a way to do that, I'd love to see a prototype from you proving me wrong :-).
With content handler you can still add random things to the db in your own custom tables, that just functionally depend on the wiki page. Im not suggesting that you parse a page each time you want a list and then merge with rc in php.
A good example of this is special:recentchangeslinked - wikipages have links, links go in pagelinks (or other depending on type) table, special page does inner join + filesort just like watchlist to get recently changed pages.
We'll also hoping to support the filtering of collections via tags which becomes much easier if stored in a database.
"Tags" is another jargon quaigmire in mw land....
Anyways no particular reason why stuff can't be canonically on a
wikipage
and extracted to db tables (in a similar fashion to link tables). Doing that gives you history, reverting, oversight, collaborative editing,
talk
pages, etc for free. (But of course im sure that has its own drawbacks)
[Also its important to keep in mind: it is easy to wax poetic on the mailing list about how something ought to be done, much harder to
actually
do it. So take my comment with the salt appropriate of somebody who
hasn't
implemented anything nor has any plans to]
A watchlist is not a wikipage, so that in my eyes sets a precedent.
Its also unequivocally private. I think a lot of the conflict here comes from the dual nature of gather as public/private.
True, but given we as a community apparently want truely public watchlists it's time to work out what that looks like :)
[..]
Agreed, this is definitely an integration problem. I'd like us to generalise our existing site features and make them less like duct tape. There is very little code abstraction which has traditionally made this difficult. I think when we say "this should be a wiki page" we actually mean something different - in that what we are really saying is "this should integrate with recent changes" or this should integrate with X. Identifying those problems will move us forward as we will find solutions to them and build better software. Starting with "it should be a wikipage" is approaching the problem from the wrong direction. This may turn out to be the solution but it's not a good way to write software efficiently.
Making foo be an instance of X is a good way to solve the problem of make foo behave like x for all properties of x, including those that don't exist yet. (Making interfaces more generic is also obviously good, but when I hear, it should do all the things wiki pages do, I naturally come to the conclusion it should be a wikipage)
So, lets turn this around - what aspects of wiki pages don't you want this to have? In my mind a wiki page has the following properties: *Is editable *contains data of some kind (not neccesarily wikitext) *is viewable (biggest conflict thus far) *integrates with tools for managing content (history, rc, revdel, etc) *has a unique name in a common shared namespace (i mean namespace in the cs sense of the word, not mediawiki sense)
Which property don't you want? Or are there other properties I forgot that you don't want? If not, what is wrong with wiki pages?
--bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 8 apr. 2015, at 21:17, Brian Wolff bawolff@gmail.com wrote:
I think the problem is one of integration. People want anything publically editable to be consistent. Earlier in this thread TheDJ made a comparison to building an office tower with duct tape. Well he has a fair point about hacky solutions, to extend the metaphor, nobody wants an office tower built of fifty different materials either, they want a unified building that looks integrated and consistent. Using wiki pages gives integration with all current site features and any future site feautres which don't exist yet, for free.
In my opinion the problem here is that there is no separation of concerns between public and private. Just make Gather private by default, and then use another system to ‘publish’ a list to the public space, with a separate content model, separate namespace (or use subpages inside User) etc.
DJ
On Wed, Apr 8, 2015 at 8:52 AM, Federico Leva (Nemo) nemowiki@gmail.com
wrote:
I hope no 60 storey building is in the making. The bazaar is
horizontal, a
vertical suk is too similar to a cathedral.
Nemo
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jon Robson
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org mailto:Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I agree that lists is a bigger thing in Wikimedia world than many people think, possibly because of lot of work on lists happens as homegrown projects by caring volunteer editors. Various personal and group task lists, backlogs[1], wikiprojects, list-based editathons, education programs, Articles needing expert attention, stub sorting, navboxes, articles that every Wikipedia should have, translation projects, plain old list articles and so on and so on.
There are also special pages that could be relevant, such as WantedPages, AncientPages, WithoutInterwiki, and many others, but they are frequently incomplete, out-of-date, and not engaging beyond showing a list. How about tracking the progress of how many pages were in the list a year ago and how many are there today? Or gentle gamifying - which user created the most articles that were on the WantedPages list over the last year?
I have this in mind for ContentTranslation: https://phabricator.wikimedia.org/T96147 Maybe it will use Gather in some way, but the really important point is that it can go way beyond translation.
[1] I remember User:Sj calling https://en.wikipedia.org/wiki/Wikipedia:Backlog "the best page on Wikipedia"; he's quite right.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
2015-04-03 1:19 GMT+03:00 Jon Robson jrobson@wikimedia.org:
I am writing to invite you to preview and hopefully contribute to Gather [1], a new MediaWiki extension that allows users to create, share, and discover lists of articles. Gather is currently available for all users of the mobile site who have opted in to beta. This launch was primarily for the community to test it and to pardon the pun... gather... some data. We would love for you to try it out and share your feedback with us.
The best way to explain what Gather lists are is to contrast them with existing facilities for grouping articles: categories and list articles. Categories and list articles exist in subject namespaces, and their goal is to provide navigational links for articles whose subjects share some common, defining property. Gather lists have a similar goal of facilitating content discovery but differ in that they allow users the ability to group articles on the basis of any criterion, whether this be overtly subjective and irreverent ("articles I enjoy"); curated on the basis of cultivated tastes and informed opinions ("the most groundbreaking discoveries in chemistry"); educational at a more localised level ("Pages that Mr Robson's A-level chemistry students should read") or simply a personal todo list ("articles i want to edit/read today").
The Gather lists you create are currently your own [A] and you decide whether or not they are visible to others [B]. To see some example lists check out: https://en.m.wikipedia.org/wiki/Special:Gather/by/Jdlrobson/23 https://en.m.wikipedia.org/wiki/Special:Gather/by/Jdlrobson/35 https://en.m.wikipedia.org/wiki/Special:Gather/by/Sonasonic/71
If you want to have a go at making your own lists you have two options (both require a mediawiki account):
- Opt in to mobile site beta:
https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions&retur... and then interact with the watchstar 2) Try it out on Vector [C]: https://en.m.wikipedia.org/wiki/User:Jdlrobson/vector.js
To build this we have looked at the existing watchlist code, the Collections extension, the multiple lists in core RFC and the many feature requests around watchlist that span the lifetime of this project. Apologies in advance for lack of documentation, sometimes talking and back and forth over IRC/coffee is more productive then writing extensive documentation, but I promise you the team has been listening to all sorts of use cases.
As a result I think now we have the first essential building block - the ability for a user to store and access a structured public or private list.
We have APIs that will allow you to:
- create new lists that are private or public
- edit lists
- add and remove pages to those lists
- query lists
- moderators to hide troublesome lists
- manipulate the watchlist which has special handling to turn it into
a collection
Next up on the immediate roadmap for those that are interested:
- Fixing up API bugs, missing documentation
- Pagination was sorely missing from the first release. Code for that
has merged so that's coming soon.
- Polishing the existing user experience and working out how to port
that to desktop
- Improving on moderation tools
- The ability for multiple users to share and manage a list
- Combining the data inside a list with other data e.g. recent changes
to make multiple watchlists. I have a first version of this patch ready for review [3] and working towards the goal of public/private watchlists [4].
We have a long way to go and I guess this is the main reason I'm writing this mail - I'm hoping to collect more help from across our community.
If you are interested in helping feel free to reach out to me off list on irc (user jdlrobson) or poke around Phabricator [5].
Thanks for the read! Jon
[1] https://www.mediawiki.org/wiki/Extension:Gather [2] http://en.wikipedia.beta.wmflabs.org/w/api.php?action=help&modules=editl... [3] https://gerrit.wikimedia.org/r/#/c/200181/ [4] https://phabricator.wikimedia.org/T9467 [5] https://phabricator.wikimedia.org/tag/gather/
[A] In the future we would love to support collaborative editing of collections. Any one interested in helping? [B] ... Although currently the UI only supports public lists... API supports both. Help us build that out. [C] Highly experimental - this is still a WIP and may have lots of kinks. I would love a volunteer full time to help me with the desktop experience. It should be noted that the Gather extension works on desktop, but we've de-scoped the work there whilst UX standardisation is ongoing and to limit the workload so we can actually get things done quickly. There is currently a dependency on MobileFrontend for convenience but we hope to drop that very soon (https://phabricator.wikimedia.org/T94100). [D] (albeit badly documented - patches welcomed!
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Apr 15, 2015 at 8:56 AM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
[1] I remember User:Sj calling https://en.wikipedia.org/wiki/Wikipedia:Backlog "the best page on Wikipedia"; he's quite right.
+1. I also like the https://en.wikivoyage.org/wiki/Wikivoyage:Maintenance_panel linked in the sidebar there.
From the tooltip explanations, to the subtle graph-lines.
I would perhaps prefer the scrolling lists in the top-row to be given a bit more vertical space, but I'm not a regular editor there so don't really have the background to advise.
Are there any/many more pages like this at other wikis, that have more unique characteristics?
(I keep hoping/waiting to see [[sparkline]]s somewhere in our articles or backend pages... :)
2015-04-17 8:53 GMT+03:00 quiddity pandiculation@gmail.com:
On Wed, Apr 15, 2015 at 8:56 AM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
[1] I remember User:Sj calling https://en.wikipedia.org/wiki/Wikipedia:Backlog "the best page on Wikipedia"; he's quite right.
+1.
Are there any/many more pages like this at other wikis, that have more unique characteristics?
I gave some examples at https://phabricator.wikimedia.org/T96147
One more example I can think of is the auto-created categories in Commons Metadata, such as "Files with no machine-readable license" - a curious combination of categories with localizable names and actual software.
wikitech-l@lists.wikimedia.org