User:Cloudii/Proposals/CategoryInteresections - Revision history

Cloudii: Cloudii moved page User:Cloudii/Sandbox/test/test2 to User:Cloudii/Proposals/CategoryInteresections

2014-02-09T23:50:07Z

Cloudii moved page User:Cloudii/Sandbox/test/test2 to User:Cloudii/Proposals/CategoryInteresections

← Older revision		Revision as of 23:50, 9 February 2014
(No difference)

Cloudii: Cloudii moved page User:Cloudii/test/test2 to User:Cloudii/Sandbox/test/test2

2014-02-09T23:47:31Z

Cloudii moved page User:Cloudii/test/test2 to User:Cloudii/Sandbox/test/test2

← Older revision	Revision as of 23:47, 9 February 2014
(No difference)

Cloudii: /* What are the cons? */

2014-02-05T01:05:48Z

What are the cons?

← Older revision		Revision as of 01:05, 5 February 2014
Line 63:		Line 63:

	===What are the cons?===		===What are the cons?===
	Calculating intersections of categories can be a memory intensive process if the categories are large (like 1000+ members. Memory-wise, it's an O(n^2) process. Luckily this extension doesn't search subcats, so its not as bad as a could be). As such, TLG (the default setting of the extension) has limited the number of results that can be shown from an intersection of two categories to be somewhere around 200 results.		Calculating intersections of categories can be a memory intensive process if the categories are large (like 1000+ members). Memory-wise, it's an O(n^2) process. Luckily this extension doesn't search subcats, so its not as bad as a could be). As such, TLG (the default setting of the extension) has limited the number of results that can be shown from an intersection of two categories to be somewhere around 200 results.

	However, as Baka-Tsuki is small, this actually doesn't pose a problem until we ever get more than a couple hundred projects. This memory issue primarily plagues big Wiki's like Wikipedia where there can be 10,000+ pages in a category. Fortunately, we're not at that size. We can afford this kind of process that loops through 100 pages. If you're skeptical, the intersection you're looking at above is an intersection of a 121-size-category and a 40-size-category.		However, as Baka-Tsuki is small, this actually doesn't pose a problem until we ever get more than a couple hundred projects. This memory issue primarily plagues big Wiki's like Wikipedia where there can be 10,000+ pages in a category. Fortunately, we're not at that size. We can afford this kind of process that loops through 100 pages. If you're skeptical, the intersection you're looking at above is an intersection of a 121-size-category and a 40-size-category.

Cloudii: /* What are the cons? */

2014-02-05T01:05:28Z

What are the cons?

← Older revision		Revision as of 01:05, 5 February 2014
Line 63:		Line 63:

	===What are the cons?===		===What are the cons?===
	Calculating intersections of categories can be a memory intensive process if the categories are large (like 1000+ members. ~~If you know CS~~, it's an O(n^2) process. Luckily this extension doesn't search subcats, so its not as bad as a could be). As such, TLG (the default setting of the extension) has limited the number of results that can be shown from an intersection of two categories to be somewhere around 200 results.		Calculating intersections of categories can be a memory intensive process if the categories are large (like 1000+ members. Memory-wise, it's an O(n^2) process. Luckily this extension doesn't search subcats, so its not as bad as a could be). As such, TLG (the default setting of the extension) has limited the number of results that can be shown from an intersection of two categories to be somewhere around 200 results.

	However, as Baka-Tsuki is small, this actually doesn't pose a problem until we ever get more than a couple hundred projects. This memory issue primarily plagues big Wiki's like Wikipedia where there can be 10,000+ pages in a category. Fortunately, we're not at that size. We can afford this kind of process that loops through 100 pages. If you're skeptical, the intersection you're looking at above is an intersection of a 121-size-category and a 40-size-category.		However, as Baka-Tsuki is small, this actually doesn't pose a problem until we ever get more than a couple hundred projects. This memory issue primarily plagues big Wiki's like Wikipedia where there can be 10,000+ pages in a category. Fortunately, we're not at that size. We can afford this kind of process that loops through 100 pages. If you're skeptical, the intersection you're looking at above is an intersection of a 121-size-category and a 40-size-category.

Cloudii: /* Cloud's Proposal */

2014-02-04T19:37:17Z

Cloud's Proposal

← Older revision		Revision as of 19:37, 4 February 2014
Line 49:		Line 49:

	==Cloud's Proposal==		==Cloud's Proposal==
	~~<small>''Taken from the from the Wikipedia Proposal page.''</small>~~

	Currently, we have a category called '''Light Novel (English)''', and twenty variations of this for every alternative light novel language.		Currently, we have a category called '''Light Novel (English)''', and twenty variations of this for every alternative light novel language.

Cloudii: /* What are the cons? */

2014-02-04T19:33:51Z

What are the cons?

← Older revision		Revision as of 19:33, 4 February 2014
Line 68:		Line 68:

	However, as Baka-Tsuki is small, this actually doesn't pose a problem until we ever get more than a couple hundred projects. This memory issue primarily plagues big Wiki's like Wikipedia where there can be 10,000+ pages in a category. Fortunately, we're not at that size. We can afford this kind of process that loops through 100 pages. If you're skeptical, the intersection you're looking at above is an intersection of a 121-size-category and a 40-size-category.		However, as Baka-Tsuki is small, this actually doesn't pose a problem until we ever get more than a couple hundred projects. This memory issue primarily plagues big Wiki's like Wikipedia where there can be 10,000+ pages in a category. Fortunately, we're not at that size. We can afford this kind of process that loops through 100 pages. If you're skeptical, the intersection you're looking at above is an intersection of a 121-size-category and a 40-size-category.

			This extension is installed on and currently used on Wikimedia projects: Wikinews, Meta, Wikibooks, and Wikiversity. Does that make you feel better about scalability and usage?

	The other con is that it isn't a real category page. We could link it to users and display like a category page (like I did above), but the default output is a straight list of results.		The other con is that it isn't a real category page. We could link it to users and display like a category page (like I did above), but the default output is a straight list of results.

Cloudii: /* What are the cons? */

2014-02-04T19:23:26Z

What are the cons?

← Older revision		Revision as of 19:23, 4 February 2014
Line 67:		Line 67:
	Calculating intersections of categories can be a memory intensive process if the categories are large (like 1000+ members. If you know CS, it's an O(n^2) process. Luckily this extension doesn't search subcats, so its not as bad as a could be). As such, TLG (the default setting of the extension) has limited the number of results that can be shown from an intersection of two categories to be somewhere around 200 results.		Calculating intersections of categories can be a memory intensive process if the categories are large (like 1000+ members. If you know CS, it's an O(n^2) process. Luckily this extension doesn't search subcats, so its not as bad as a could be). As such, TLG (the default setting of the extension) has limited the number of results that can be shown from an intersection of two categories to be somewhere around 200 results.

	However, as Baka-Tsuki is small, this actually doesn't pose a problem until we ever get more than a couple hundred projects. This memory issue primarily plagues big Wiki's like Wikipedia where there can be 10,000+ pages in a category. Fortunately, we're not at that size. We can afford this kind of process that loops through 100 pages.		However, as Baka-Tsuki is small, this actually doesn't pose a problem until we ever get more than a couple hundred projects. This memory issue primarily plagues big Wiki's like Wikipedia where there can be 10,000+ pages in a category. Fortunately, we're not at that size. We can afford this kind of process that loops through 100 pages. If you're skeptical, the intersection you're looking at above is an intersection of a 121-size-category and a 40-size-category.

	The other con is that it isn't a real category page. We could link it to users and display like a category page (like I did above), but the default output is a straight list of results.		The other con is that it isn't a real category page. We could link it to users and display like a category page (like I did above), but the default output is a straight list of results.

Cloudii: /* What are the cons? */

2014-02-04T19:21:31Z

What are the cons?

← Older revision		Revision as of 19:21, 4 February 2014
Line 67:		Line 67:
	Calculating intersections of categories can be a memory intensive process if the categories are large (like 1000+ members. If you know CS, it's an O(n^2) process. Luckily this extension doesn't search subcats, so its not as bad as a could be). As such, TLG (the default setting of the extension) has limited the number of results that can be shown from an intersection of two categories to be somewhere around 200 results.		Calculating intersections of categories can be a memory intensive process if the categories are large (like 1000+ members. If you know CS, it's an O(n^2) process. Luckily this extension doesn't search subcats, so its not as bad as a could be). As such, TLG (the default setting of the extension) has limited the number of results that can be shown from an intersection of two categories to be somewhere around 200 results.

	However, as Baka-Tsuki is small, this actually doesn't pose a problem until we ever get more than a couple hundred projects.		However, as Baka-Tsuki is small, this actually doesn't pose a problem until we ever get more than a couple hundred projects. This memory issue primarily plagues big Wiki's like Wikipedia where there can be 10,000+ pages in a category. Fortunately, we're not at that size. We can afford this kind of process that loops through 100 pages.

	The other con is that it isn't a real category page. We could link it to users and display like a category page (like I did above), but the default output is a straight list of results.		The other con is that it isn't a real category page. We could link it to users and display like a category page (like I did above), but the default output is a straight list of results.

Cloudii: /* Why is this better? */

2014-02-04T19:19:43Z

Why is this better?

← Older revision		Revision as of 19:19, 4 February 2014
Line 60:		Line 60:
	'''Less categories overall. Simpler organization. Readers get to see what they want and ''only'' what they want.'''		'''Less categories overall. Simpler organization. Readers get to see what they want and ''only'' what they want.'''

	For example, right now, I'd like to be able to see all English Projects that are stalled. However, the current [[:Category:Inactive Projects]] lists all inactive projects of all languages... which we have 40 of, which is not easy to look at.		For example, right now, I'd like to be able to see all English Projects that are stalled. However, the current [[:Category:Inactive Projects]] lists all inactive projects of all languages... which we have 40 of, which is not easy to look at. It's the problem the old Teaser Projects category page had.

	I could request that we split that category up into '''Inactive Projects (English)''', but do we really need that many more categories?		I could request that we split that category up into '''Inactive Projects (English)''', but do we really need that many more categories? It's unnecessary, and certainly not ideal. Fully populated primary categories are better and more powerful, if intersections between categories can be easily performed.

	===What are the cons?===		===What are the cons?===

Cloudii at 19:16, 4 February 2014

2014-02-04T19:16:44Z

@@ Line 1: / Line 1: @@
-<!-- ignore this <DynamicPageList>
+__NOTOC__
-category = Light novel (English)
+=Proof of Concept of Category Intersections=
-category = Inactive Projects
+Brought to you by [http://www.mediawiki.org/wiki/Extension:DynamicPageList_(Wikimedia) Extension:DynamicPageList] (TLG already installed it!)
-ordermethod = sortkey
+==Sample: Intersection of Light Novel (English) and Stalled Categories==
 {| width=100%
@@ Line 45: / Line 39: @@
 |}
-blah
+The other con is that it isn't a real category page. We could link it to users and display like a category page (like I did above), but the default output is a straight list of results.