Talk:Wikikernel

Suggestions on how Wikikernel would fit in the project proposal process.

As of 21 March 2006 the process for proposing new projects is as follows:

1. If not already done so, a person creates an account and a user page, so that others may contact that user with any questions,
2. A proposal is add to the list on the proposals for new projects page,
3. Discussion then takes place among those interested in the proposal,
4. An interest poll is conducted where a vote is taken,
5. The proposal and the results of the poll are forwarded to the board for consideration.
6. The board may choose one of the following courses of action:

• Reject outright,
• Approve outright,
• Approve for beta setup,
• Reject pending proposal revision (ie Wikiversity).

Before everything else

pros

• Demo is already set-up
• Could possibly clean-up the proposals page

cons

• Would usually require extensive seed-posting by proposer.
• Would require a formal change in New project policy by actually requiring a demo to be created.

In place of or as a supplement to discussion

pros

• Those interested would be able to begin seeding the project proposal
• Could be used to guage interest in proposal

cons

• Place cons for this suggestion here

When a certain criteria is met at the completion of the interest poll

pros

• Place pros for this suggestion here

cons

• Place cons for this suggestion here

Upon recommendation of the board

pros

• Place pros for this suggestion here

cons

• Place cons for this suggestion here

Making the jump from general interest discussion to poll

I've seen many new Wikimedia project proposals get started, and by far the hardest part is trying to make the jump from a general interest discussion that may have at most a few dozen interested participants to a full interest poll that brings in the full Wikimedia community. The #1 largest hurdle is the requirement to translate the proposal page into multiple langauges, and that makes it very difficult to even schedule a vote. Without a deadline, it seems as though getting the translations done won't really happene either. My experience with the Wikiversity vote was that once the voting started, many other languages are added to the list of translations, although it helps to have an initial core to start with that is more than just English and/or one other language.

One example of IMHO a failed user interest poll is Wiki for standards, which jumped the gun a little bit and started the poll before even working out what the proposal was all about. I got into a major argument over this very point, even though I supported the concept as proposed in a general sort of way. (Indeed I even wrote a very similar proposal earlier). Time will tell if the Wikimedia Foundation board will approve or reject the proposal, but I'm not holding my breath.

b:Wikiversity is a good example of what can happen if you allow a seed wiki to get started and help develop a proposal. It is an amazing concept, and now has many people working on it. Why not allow other project to do the same thing? Wikibooks, however, is now discouraging this sort of practice and that is more the reason for trying to establish this project to create a new seed wiki of some sort.

A key element of this proposal is that a much smaller interest survey can be developed that doesn't require a Wikimedia-wide vote or advertising on all of the Water Cooler pages on all of the Wikimedia sites. That should be reserved for projects that have proven viability. --Roberth 18:45, 23 March 2006 (UTC)

name

I suggest the name of this project to be wikincub or wikincubation. what's the yours opinion?--Vipuser 08:25, 28 March 2006 (UTC)

Make sure that you visit Wikikernel/Names for some other suggestions for possible names of this project. From an admittedly small pool of participants, the current leaning is toward something simple like Wikimedia Trial Wiki, but I could imagine other names. I also like the idea of a simple URL like http://trial.wikimedia.org/ --Roberth 19:39, 29 March 2006 (UTC)

What about hosting new languages for existing Wikimedia projects?

I think this requires a whole sub-section for policy discussions, but it is an interesting idea. This proposal has been written with the idea that whole new sister projects can be created. It was brought up on Foundation-l, however, that a need exists for some place to experiment with the creation of content for new langauges that aren't currently available on existing Wikimedia projects. Something like the Hatian Creole Wikibooks or whatever.

I see this as also opening a can of worms in terms of enforcement, as there are some new language proposals that are being openly political now. I can name several examples, but I don't want to get anybody angry at the moment toward this proposal. Even the whole issue of the viability of constructed languages like Klingon or Neo as a seperate Wikipedia gets into a huge series of debates.

I think it is reasonable to expect new proposals for langauges to go through the same process that the other proposed Wikimedia projects go through, at least for inclusion into this Wikikernel project. The problem with this is that my goal was to make it as easy to create a new project like b:Errata or b:Wikiversity as it currently is right now for simply creating a new language sub-domain for Wikipedia. If you have to go through the hassle to have a vote, then why go through the extra bureaucracy of trying to set up something on a test wiki?

The one benefit would be that administrators and bureaucrats would be in place to help these new project get their initial set of pages in the beginning, and perhaps suggest that new language subdomains can't be started until after they have created over 100 pages of original content? --Roberth 20:20, 29 March 2006 (UTC)

Meta

Why can't this be part of Meta? Andrevan 00:58, 7 April 2006 (UTC)

I'm sorry that I havn't been responding as fast as perhaps I should be... I've been on a Wikibreak.

The real reason why this can't be a part of Meta is that Meta doesn't want it. I have specifically asked both on Foundation-l and on the Meta:Babel page if it would be considered acceptable for content of this nature to be put here on Meta. The problem is that the admins for Meta are frankly overwhelmed, and this is content that really needs a specialized group of individuals who would be willing to police the content according to very different criteria than would normally be considered unacceptable or acceptable on Meta. Yes, it would be nice if you could put a starter demo project on Meta, and I've even tried to do that myself.

The fact is that culling procedures for failed projects need to be established, as will procedures for establshing new demo projects. This whole process with Wikikernel (or any related proposal... this doesn't have to be the only one) is self-contained and can provide the additional support to help get demo projects started. This also allows a level of experimentation with things like the style sheets or even programming changes to MediaWiki software that would not normally be considered acceptable for Meta as well.

In short, a seed wiki is something that needs to be its own project, and all of the policies that are obvious for a project like this also need to be established if content of this nature is hosted on Meta. --Roberth 15:39, 30 May 2006 (UTC)

Proposing a new "Table:" special namespace

Editing tables and importing them in Wiki articles is a nightmare to maintain.

I propose a new "Table:" namespace, with a dedicated editor to add lines or edit cells. This could also be supported by native SQL tables.

The editor also offers a way to edit it in "raw" mode, with one record per line, in CSV-like format (separated by | or ; using a simple format selector, or even using the Wiki table format, where table presentation would be ignored). This would allow easy creation and maintenance of these datas from bots and spreadsheets.

The first row in the table would contain column names (no need to support datatypes at first, but this could be added later with a meta-data editor, separate from the actual CSV-like data).

Then articles couldpropose different views of these datas (such as alternate sorts, or sub selections, using very basic syntax).

Then, to use this data in articles, we use a syntax like this:

<head><!-- this section does not generate any content in the article itself, it contains directives or declarations
such as declaring tables, or embeded stylesheets -->
{{#table:ctry|Table:Country}}<!-- this line is invisible in the generated HTML, just links to the table data -->
{{#table:lang|Table:Language}}<!-- this line is invisible in the generated HTML, just links to the table data -->
</head>
Here is the population per country, and 
{|border="1" cellspacing="0" cellpadding="1" class="wikitable"
{{#foreach:ctry|orderby:enName}}
{{#foreach:lang|where:lang.code=ctry.lang}}
|-
!colspan="3"|Country
!Population
!colspan="2"|Language(s)
|-
|align="left"|{{#data:ctry|code}}
|align="left"|{{#data:ctry|enName}}
|align="left"|({{#data:ctry|localName}})
|align="right"|{{#data:ctry|population}} hab.
|align="left"|{{#data:lang|enName}}
|align="left"|({{#data:lang|localName}})
{{#endfor:lang}}
{{#endfor:ctry}}
|}

Aggregates would not be supported, (but there may exist away to fill another table from the result of a more complex query. At first, complex queries would be computed outside of Wikipedia and their result imported.)

In a first implementation, join options would not be supported (but it would still be useful as it would allow easy imports from bots, or from external spreadsheet and databases), but selection by constant (to output only parts of the table) and simple sorts by column should be supported.

The "Table:" namespace would be visitable like a normal Wiki article, using only a default presentation for viewing the data. But it should be allowed to import tables shared by other wikis (like images from Commons).

Of course, the generated page should be cached, to avoid performing too often the query. That's why there's a initial declaration of tables used, and this should allow checking fast if it must be imported again in the article

The #table declaration has the same effect as including a embedded wikitable where it is used. So the above could be written as well out of the "Table:" namespace like this:

<head><!-- this section does not generate any content in the article itself, it contains directives or declarations
such as declaring tables, or embeded stylesheets -->
{|id="ctry"
|-
!code!!enName!!localName!!population!!lang
|-
|at||Austria||Österreich||22.0||de
|-
|de||Germany||Deutschland||80.2||de
|-
|fr||France||France||62.0||fr
|-
|gb||United Kingdom||United Kingdom||45.0||en
|-
|it||Italy||Italia||40.0||it
|-
|us||United States||United States||150.0||en
|}
{|id="lang"
|-
!code!!enName!!localName
|-
|de||German||Deutsch
|-
|en||English||English
|-
|fr||French||français
|-
|it||Italian||italiano
|}
</head>

Here is the population per country, and 
{|border="1" cellspacing="0" cellpadding="1" class="wikitable"
{{#foreach:ctry|orderby:enName}}
{{#foreach:lang|where:lang.code=ctry.lang}}
|-
!colspan="3"|Country
!Population
!colspan="2"|Language(s)
|-
|align="left"|{{#data:ctry|code}}
|align="left"|{{#data:ctry|enName}}
|align="left"|({{#data:ctry|localName}})
|align="right"|{{#data:ctry|population}} millions hab.
|align="left"|{{#data:lang|enName}}
|align="left"|({{#data:lang|localName}})
{{#endfor:lang}}
{{#endfor:ctry}}
|}

This last form would be the one maintained in the cache (and the cache would be refreshed only if the declared table was edited and changed).

00:17, 14 May 2006 (UTC)

I don't know what this has to do with Wikikernel other than being another new project proposal. Unfortunately, by burying this explaination here, instead of with Wikidata where it belongs, it will get lost and ignored. --Roberth 15:42, 30 May 2006 (UTC)

Incubator

Incubator is for new languages of existing projects, not completely new projects. 24.68.146.148 15:40, 13 March 2015 (UTC)