Lists as first class citizens

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Lists as first class citizens

Jon Robson-2
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&returnto=Serge+Gainsbourg
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=editlist%7Cquery+listpages%7Cquery+lists
[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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Pine W
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 <[hidden email]> 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):
> 1) Opt in to mobile site beta:
>
> https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions&returnto=Serge+Gainsbourg
> 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=editlist%7Cquery+listpages%7Cquery+lists
> [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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Risker
In reply to this post by Jon Robson-2
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 <[hidden email]> 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):
> 1) Opt in to mobile site beta:
>
> https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions&returnto=Serge+Gainsbourg
> 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=editlist%7Cquery+listpages%7Cquery+lists
> [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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Kevin Wayne Williams
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Alex Monk
Collections are already taken as well:
https://www.mediawiki.org/wiki/Extension:Collection

On 4 April 2015 at 16:15, Kevin Wayne Williams <[hidden email]>
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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Brian Wolff
In reply to this post by Kevin Wayne Williams
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" <[hidden email]>
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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Risker
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 <[hidden email]> 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" <[hidden email]
> >
> 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
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

John Mark Vandenberg
In reply to this post by Brian Wolff
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 <[hidden email]> 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" <[hidden email]
> >
> 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
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Derk-Jan Hartman
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, [hidden email] 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 <[hidden email]> 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" <[hidden email]
>>>
>> 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
>>> [hidden email]
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Federico Leva (Nemo)
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Jon Robson
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) <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Risker
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 <[hidden email]> 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) <[hidden email]>
> 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
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Jon Robson
> * http://jonrobson.me.uk
> * https://www.facebook.com/jonrobson
> * @rakugojon
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Adam Wight-2
In reply to this post by Jon Robson
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 <[hidden email]> 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) <[hidden email]>
> 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
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Jon Robson
> * http://jonrobson.me.uk
> * https://www.facebook.com/jonrobson
> * @rakugojon
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Brian Wolff
In reply to this post by Jon Robson
On Apr 8, 2015 2:59 PM, "Jon Robson" <[hidden email]> 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) <[hidden email]>
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
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Jon Robson
> * http://jonrobson.me.uk
> * https://www.facebook.com/jonrobson
> * @rakugojon
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Bartosz Dziewoński
On Wed, 08 Apr 2015 21:17:44 +0200, Brian Wolff <[hidden email]> 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. :)

--
Bartosz Dziewoński

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Jon Robson
In reply to this post by Brian Wolff
On Wed, Apr 8, 2015 at 12:17 PM, Brian Wolff <[hidden email]> wrote:

> On Apr 8, 2015 2:59 PM, "Jon Robson" <[hidden email]> 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) <[hidden email]>
> 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
>> > [hidden email]
>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>>
>> --
>> Jon Robson
>> * http://jonrobson.me.uk
>> * https://www.facebook.com/jonrobson
>> * @rakugojon
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Derk-Jan Hartman
In reply to this post by Brian Wolff

> On 8 apr. 2015, at 21:17, Brian Wolff <[hidden email]> 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) <[hidden email]>
> 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
>>> [hidden email]
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>>
>>
>> --
>> Jon Robson
>> * http://jonrobson.me.uk
>> * https://www.facebook.com/jonrobson
>> * @rakugojon
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email] <mailto:[hidden email]>
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l <https://lists.wikimedia.org/mailman/listinfo/wikitech-l>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Brian Wolff
In reply to this post by Jon Robson
> > 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Daniel Kinzler
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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Lists as first class citizens

Amir E. Aharoni
In reply to this post by Jon Robson-2
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 <[hidden email]>:

> 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&returnto=Serge+Gainsbourg
> 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=editlist%7Cquery+listpages%7Cquery+lists
> [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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12