Talk:Proposals for new projects/Archive 1

Process Wiki edit

A wiki devoted to explaining processes and how to's, for example instructions for joinery or metalworking or cooking ect. could include everthing from photoshop tutorials to instructions on how to upgrade your 54 chevy's drum brakes to disk brakes.

Further development of rejected Summer of Code 2006 projects edit

Some of these could be for Summer of Code 2007, others should be integrated with the ordinary proposals for new projects. Because the preparation for Summer of Code 2006 was extensive, it provides a good annual snapshot of what needs to be done. Perhaps there must be a proposal protocol/pipeline that takes ideas and turns them into specific types of projects depending on scale, complexity, integration areas addressed, skills required, etc.

Frontend/UI edit

Integration with existing desktop software edit

wikidPAD edit

Now open source to its front page. Uses a terrible WikiWord convention. Upgrading it to let users smoothly wikify plain text notes into a wikitext standard would add to mediawiki's status as the standard wiki database. Some tikiwiki users are hot on it and may already be planning better integration with that wiki software.

Also coordinating with Jabber projects including an inbuilt jabber wiki, would help cut down on the number of crappy wiki formats.

IM and presence edit

Use Instant Messaging (IM) protocols to provide “presence” -- say whether a user is online in their chat client. User preference sets user ID, protocol. Where possible, provide links to launch IM client to chat with a user. This should be an extension. See also ICQ_extension

Use of the jabber.org ID as a standard wiki identity is a closely related issue.

Better support directly for Trillian Instant Lookup - which links wikipedia pages when the names of articles show up in chats, is another closely related issue.

Video and audio (browser or plugin capabilities) edit

No-install in-browser display of video (and audio) clips for Wikimedia Commons, using reasonably common Java and/or Flash components. Needs to be able to 1) play MP3 files - especially useful if they can be made to play when a show/hide=play/stop page feature is used. 2) play or transparently pre-convert Ogg Theora videos, 3) avoid use of patent-encumbered formats. Consider integration of Fluendo's Cortado player applet as a starting point.

New desktop software and related capabilities edit

Offline reader and multi-level import edit

An offline reader of mediawiki-based services such as Wikipedia. This can include: software to browse the offline version, which enables an updated version of the page (or a full-size image) to be fetched; software to create a well-compressed dump of a certain size/with a selection of articles; software makes decisions on what to do when a link leads to an article which is not on the CD or DVD.

Another feature that would be extremely effective would be a general facility to resolve links with hidden redirects from local dynamic (hard drive or USB flash drive) versions to local static (CD or DVD) versions, to shared group versions such as an intranet (using the preference facilities if these are available), to shared groups on a public service like Wikipedia itself, or perhaps the publicly visible article on some specialist service - maybe a Wikipedia mirror like Wikinfo.org which is more supportive of articles on specialist terms of art from the point of view of that art (sympathetic). A closely related issue is permanent wiki merges of entire databases, and integration of non-wiki corpus like email archives

This might be best implemented in AJAX.

wiki-based crit clone edit

The capabilities of crit.org, now seemingly no longer available, would be another facility worth integrating. Crit.org allowed users to attach thread-based comments with typed links to form a semantic web, but it allowed them to be attached to any web page. Effectively crit.org added threaded subpages to every page on the web! Adding mediawiki subpages to every page on the web would be much more useful, however. Especially in combination with a preference capability that let groups share specific sets of comments not seen by others.

Uclear whether this is best done on the front end or the back end, but likely best as front end capabilities on an offline reader.

XHTML2Wiki conversion edit

Uploaded HTML-page (any other uploaded document or simple URL) automatically parsed and saved in the database as wikitext. See also proposals for backend storage of database in XML, as some other wikis do, and integration of HTML and plain text.

Also possibly best integrated as an extension of an offline reader, since it is part of submitting a new page.

External Editor helper app edit

MediaWiki has support for external applications for editing images, sound files, and wiki pages -- see the linked page for details. This is done using a helper application which negotiates between MediaWiki and any external applications. Currently there is only a reference implementation of this helper application in Perl/GTK. A nice, easy to install, graphical cross-platform (Qt? wxWindows?) application would be useful.

Customization per user or user group edit

Some of the capabilities proposed for the offline reader could be integrated in the existing UI, and others would require significant information about the user to be stored in backends.

Extensible user preferences edit

Provide an API for extensions to add user preferences, so that e.g. a new tab shows up in the preferences or a new preference shows up in an existing tab. This would probably be good to do alongside the admin panel idea above. It could define a few basic types including strings, numbers, booleans and colours, as well as some simple rules for when to show/hide or enable/disable settings. brion 21:09, 29 April 2006 (UTC) says this is partially done, but there is always more to do:Reply

A particularly powerful user preference capability would be personal notes seemingly attached to pages as part of the page itself - especially in combination with groups, so that members of the group could attach notes to pages that are visible only to others in those groups. A possible use for these is parallel talk pages specific to a faction (which could include a corporation or specific creative project). If these notes could be automatically compiled into a portable zip file that any member of the group could download on demand, and restored to another mediawiki database, groups might prefer to participate in Wikipedia rather than produce proprietary research documents. It might also be made easy to generate GFDL XML pages for export that mark the additional/group/personal notes as GFDL Secondary Sections, and the origins of each section including the main article in a GFDL Invariant Section. This would encourage the use of mediawiki for such purposes as think tank research papers because distributing a Wikipedia article with additional added-value notes from very qualified authors would become very easy, with credit for their work guaranteed in this way. (It's also possible to support a parallel Creative Commons license framework in this way)

Improved/integrated recent changes, related changes, what links here, contributions, watchlist edit

The social software features of mediawiki are a particular strength compared to rivals like tikiwiki whose social features are weak by comparison. The main reason mediawiki works so well to build social capital is because it's use of user pages, user talk pages, talk pages, all fit within the wiki format. Also because related changes, recent changes, contributions, "what links here" all look so much alike. The only thing tikiwiki does better is providing a list of backlinks on a menu on every page - but this doesn't include redirects to the page in question so is of limited use.

The main improvement would be better integration of all mediawiki-based changes one cares about. Show information from multiple wikis (e.g., many Wikimedia sites, or many Wikia sites, those from other mediawiki-based services, any or all of these plus a local mediawiki, or shared notes pages on a wiki per user preferences above) on one page. A related issue is the one-time merger of several databases - see synchronization below.

There is already an enhanced, more JavaScripty Special:Recentchanges which any logged in user can activate in their prefs. The enhanced version is a playground where you could try out all kinds of nifty UI paradigms, from lazy loading of diff previews to personalized client-side filters for highlighting or hiding changes. It's also well worth looking at pbwiki.com's recent changes: it is really convenient since it uses a crossout/included colour-coded form, and each change is visible under a show/hide +/- pair. Very fast to consult. Also uses English words like "changed", "added", "reverted" so each line is a sentence fragment. Very nice. Easy to read.

Besides Special:Recentchanges and Special:Relatedchanges, logical candidates would be Special:Contributions and Special:Watchlist; the latter two depend on a standard wiki identity being recognized across all wikis. This need not be a single login but more of a sovereign identity - people could voluntarily associate many accounts with this common identity for others to see.

It's also possible to involuntarily associate accounts with a common identity, but this is best done with a group/faction support system - see user preferences section noted above and alleged and collective identity.

Forms and fields edit

Wiktionary Page/Form Templates edit

Allow wikipages to be more (predefined) structured, like wiktionary (IMHO) badly, badly needs. The user gets a HTML form he fills the concrete fields in (and no longer one big texteditor field with a big mess of wikitemplatecode)

Upload form improvements edit

  • Allow multi-file upload,
  • Show progress during upload
  • Preview the upload summary
  • Add a nifty edit toolbar as for regular edits
  • Make it easy to add categories -- lazy loading AJAX category tree? Duesentrieb Tool is a candidate
  • Being able to run the upload form as a pop-up without the surrounding skin might also be useful for integration with edit.
  • Useful if could point at a folder and it uploads all files within, presenting a summary list with possibility to remove before confirmation, offering a separate summary line for each (to note say license concerns specific to a file)
  • Ability to specify filename plus incremental numbering if desired or use file name of originals - or modify all names according to some formula. Uploads can't be stored in any desired folder without php code hacking right now (only hashed dirs or just /images dir). Talking about the edit integration it would be useful to say that FCKeditor has some js api for uploads, but afaik it's not fully integrated with MW yet.

Things maybe only administrators can really get excited about edit

Try to remember that some problems only arise in really huge applications like Wikipedia and that in those applications it may be better to throw hardware at the problem than make software more complex. And, a unified toolkit can't usually be created until there is lots of experience and a very stable set of interfaces to other software, else it changes so fast you can't expect much re-use.

Unified javascript toolkit edit

Wikipedia editors and administrators currently have a massive library of Javascript bits and pieces to speed up repetitive work. However, it isn't easy for an admin to find these pieces and activate them in their account. Much code is copied and not re-used between scripts. -Manipulate the javascript library with the wikimedia user interface: "the wiki is the code."

See also Wikipedia:WikiProject User scripts.

This is closely related to AJAX questions.

Performance optimization edit

Use advantages of iframes or/and JavaScript & Divs to optimize the use of traffic, increase speed, decrease server actions and preserve existing caching scheme

  • Avoid unchanged data reload;
  • Dynamic download of page changes;
  • Client-side XHTML transformation;
  • Сlient-side password encryption;
  • JS view/edit switching without requests;

Simplifying the user interface edit

Universal login edit

All the Wikimedia projects should only require one login to access all of the projects. I know this will be a hassle for those of us with many accounts, but it would be much more convenient for all the projects to have only one login for access to all of them. I don't know how such a thing would be programmed, but it surely can be done.

See Single login specifications for this proposal. Daniel () Check out Wikiscope! 11:19, 17 July 2006 (UTC)Reply

Mobile version edit

Nothing forces you to use simple short words like a mobile version!

Tikiwiki presents any page in a different format with &mobile added onto its name. It uses HawHaw for this. Mediawiki should do the same. This implies doing a better job of using fewer, shorter, words, with more control over the presentation using CSS, like tikiwiki themes. The socialtext miki software demonstrates how to get a lot of functionality onto a tiny screen. This definitely implies changing command verbs, so it's best undertaken in conjunction with a general cleanup of the way mediawiki uses words:

Cleaning up standard language to avoid metaphors and uppercase edit

There's some terrible mixed metaphors and overuse of capitalization in the standard mediawiki package. Here's a decent analysis of it with workarounds that some sysops use.

We all know how hard it is to train users to use proper capitalization, so the user interface should help, not hinder, this, by using capitalization as little as humanly possible. For instance, "upload file", "special pages", not "Upload" or "Special". Users will see this and write nonsense like "Some Special Pages I Would Like To See" and so on... then they will do it for articles with titles like "The 2006 Congressional Election". Argh.

The metaphors are possibly worse. There is a "toolbox" which implies that pages are devices that are fixed or affected by tools. Within this, there is "What links here" which (uses capitalization differently and also) implies that a page is a place. Is it? Or does this just make geographic data integration harder (when you add GIS, "where" has a real meaning!). Within the "navigation" box, again a spatial metaphor, we have "Goings-on", "Help", "Donations", none of which are really about space, but rather about instruction or support or community. These mixed metaphors and non-standard use of capital letters really confuse people to whom English is a second (or later) language.

For best practices in this, see seedwiki.com which uses short words with almost no metaphor or dross, all lowercase. So "changes" or "pages" means "the recent changes" and "all pages". And "versions" means just that. It's better to get rid of terms like "history". As noted in the recent changes improvements project, also, using words like "added", "changed", "reverted" and other conventions than those of Unix diff, would make that log more readable.

And let's not even get started on "discuss" versus "talk" or the "community" portal. You are not talking, and it isn't necessarily a community (now or ever), it might be many communities arguing. Trying to tell people that typing is talking and trolls are a community is just more ideology and metaphor that shouldn't be there in the standard installation package.

For more on this problem see this analysis of stupid mediawiki metaphor objectionable to people who study this kind of problem and seem appropriately nitpicky to really define it.

Universal translator edit

Get rid of "lost in translation" bad search engine translation. Replace it with smarter translation that relies on the links between "the same" Wikipedia article in different languages, which acts as a high level phrase dictionary for many very specialized terms. Only if the phrase is not found in Wikipedia should the ordinary keyword translation method be used.

This might make machine translation of documentation a hell of a lot easier, so it counts as simplifying the user interface.

Backend edit

Some projects are already underway:

  • Don't mention a mediawiki client API since a number of people are actively working on such already.
  • Don't mention OpenID since it's "orthogonal to our internal account unification." --brion 18:34, 27 April 2006 (UTC) - this is a stopgap, though: note sovereign identity issues above. Eventually some standard solution to this must be found that isn't specific to mediawiki.Reply
  • Structured discussion is already being added. There will probably be more to do, though. Current discussion format has advantages and will need to be improved not just abandoned. The LiquidThreads or tikiwiki comment models are far less flexible and there are some things mediawiki users do (like answer others inline, and correct spelling errors or typos) that are extremly constructive and cooperative but which are forbidden in those other models

I18N re-architect. edit

Some developers have talked about re-writing the internationalization (i18n) section of MediaWiki to use different language files (e.g., gettext or XML).

I18n search index edit

MediaWiki search does not work well at languages without spaces between words, such as CJK. Need to implement some index system to improve that. Further, a search could be tolerant of spelling variants (see the Alemannish wikipedia). Google search is a model- but has the irritating habit of proposing alternatives with nothing behind them.

Sociosemantic web edit

See semantic web, sociosemantic web, typed link, person DTD, meeting DTD, spacetime DTD and other related issues.

TIPAESA edit

The TIPEASA format and the more limited IPA (issue/position/argument) format have caught on with especially politically motivated wikis like dkosopedia.com. A lot of people also do meeting agendas and minutes in wiki, which this format is very suited for and for which some rules now exist. Tools to support such uses would be similar to the discussion support tools now being created, where each issue is a topic, each position is a subtopic, each argument below that, and issues would turn over

RDF and semantic wiki edit

Use wiki technique to create machine-readable semantic data (such as RDF). Examples: geo-data, relationships, identifiers. Some extensions (like experimental Semantic MediaWiki or RDF extension in production on e.g. Wikitravel) already exist to do this, and this might remain in extensions. See also microformats entry, below.

Alerts, reports, ratings, statistics edit

Message system edit

Send alerts over ICQ (or something similar) to persons if something in Wikipedia happens, like changing of a watched article. Could tie into existing e-mail notification.

Article quality rating analysis edit

Work out ways of combining ratings of different versions of articles from different sources that estimates the "true" quality profile of an article as well as possible, whilst rejecting noise and outliers, and resisting attempts to game or spam the ratings system. You may need to collect some real data somehow.

Realistically, any scoring system can and will be gamed. This information goes on the back end because it's strictly advisory, and will always require human intervention to correct.

Heuristics for vandalism edit

Some heuristics for wiki vandalism already exist for the IRC notification module. The next step would be using those heuristics internally in the Web app, perhaps flagging suspicious edits, or workflow (let admins “claim” a bad edit to work on). Extended heuristics may use Bayesian filters. – clean hooks for gathering info, clean hooks to tag things, and then having the tagged info available, and then tool-building, like Spamassassin's rules engine.

Another approach to this is a revert currency possibly used only by administrators to watch editors who tend to have more lines reverted than retained. Also behaviour like sysop vandalism, ad hominem revert, ad hominem delete, or Young Jacobins all tend to make reverts stick for reasons that have nothing to do with article quality, so it's a bad idea to over trust such information. See an open letter to Jim Wales for just a little taste of what some users think of 'just trusting' a mob of sysops to decide things.

Other reports edit

The English Wikipedia has a variety of useful reports which editors use to zero in on problem articles. There is an existing Perl code base for some of these (see Toolserver/Reports) but it needs bug-fixes, integration with the Toolserver (or other platform, so they can be run automatically), the possibility for editors to mark false positives and "dealt-with" articles, improvements based on editor suggestions, and expansion to cover more reports.

Other statistics edit

Statistics integration into MediaWiki. These include user statistics, characteristics about articles and graphing the development. Most tools are currently external and not working together. Yet.

A particularly important statistic is the Markov chain transit from one link to another. That is, we know how many people look at George W. Bush. But we do not know how many got there from looking at moron just previously, and that's very important.

Integrating non-wiki data edit

Mail integration edit

Some wikis support turning email messages directly into wiki pages. Email conversations that use quoted-text or other conventions could be translated relatively easily into talk page format, or the LiquidThreads model now being integrated.

A closely related issue is simple ideology of Wikitax which integrates the ways that conversations, names and dates typically appear in email, chat, and other media.

Integration with GIS edit

Make the spacetime DTD actually work. Co-author the proposal with Free Earth Foundation which is already doing projects with Summer of Code

Improving back end storage, wikifying sets of documents, export/import edit

Merging multiple wikis edit

Something like MoinMoin's synchronization project would be very useful. More dynamic synchronization as suggested in the offline reader project would be helpful.

Evaluate PostgreSQL or plain XML as an alternative database for MediaWiki edit

There are three parts to this:

  • get this existing PostgreSQL support working properly again
  • benchmark it on heavy simulated loads
  • study the scalability of using Postgres' built-in replication support for large installations such as Wikipedia
  • see: http://pgfoundry.org/projects/wikipedia/

Another alternative database possibility is to just store everything in XML in filesystems. Why not? Mediawiki is essentially a front end, it's not ideal as a means of storing things,and then you gain all the advantages of shared filesystems and XML tools on the back end.

Tikiwiki can store its back end in multiple ways. Look at that for an idea of how to do it.

Export edit

This makes mediawiki more dominant as a way to store data.

  • Parse Wiki markup into XML, and then do fun things to that. Possibly export to other formats, maybe using XSL. See Magnus Manske's tool.
  • Export to various (could be non-XML) formats : PDF, LaTeX, DocBook, OpenOffice, Office, tikiwiki, etc. already done, someone must integrate it into Mediawiki.
DocBook BackEnd - add a DocBook based backend, so that contents can be saved natively in DocBook format in order to be directly available in a large number of arbitrary output formats, see RFE#4073 and Magnus Manske's tool

Media repository (Commons) integration edit

This might best be done in common with Creative Commons Summer of Code projects.

MediaWiki has basic support for a central media repository; this is to allow any Wikimedia wiki to transparently use files from the Wikimedia Commons, a free media archive containing over 500,000 files. However, integration with the other Wikimedia wikis could be improved in several ways:

  • Compute hashes of uploaded files and compare them for dupe checking both against the local and the repository wiki.
  • Track usage of files across wikis (currently this is done using an external tool)
  • If files are in use, show a warning message in the repository.
  • Support logging deletions from the repository to all using wikis.
  • Support uploading directly from a local wiki to the repository (may depend on single login work to be completed).
  • Support one-click "copy to Commons" -- copy an image from the local wiki to the commons wiki.
  • Support one-click "move to Commons" -- copy to Commons, and then delete the local version.
Isn't there somebody working on this already? --brion 02:39, 26 April 2006 (UTC)Reply
With the exception of the check usage tool mentioned above, I'm not aware of any work in that area. If you're thinking of Magnus' tool, it only generates wikitext for copy and pasting from one wiki to the other.--Eloquence 09:44, 26 April 2006 (UTC)Reply

Storage through diffs edit

MediaWiki currently stores the full text of each revision of an article. This storage method is inefficient. An incremental storage method based on text diffs would be much more efficient. However, performance considerations must be taken into consideration. It is probably a good idea to store the full text of the latest revision as well as n-incremental revisions, just to keep the load down. For sites like Wikipedia, incremental revision storage will significantly reduce the size of the database. The preceding unsigned comment was added by IndyGreg (talk • contribs) 18:05, 3 May 2006 (UTC)

I was under the impression that the software already did this. Relevant link? Mdd4696 21:36, 3 May 2006 (UTC)Reply
MediaWiki can store old revisions in compressed format (using gzip), but does not currently store this data using text-based diffs. --IndyGreg 23:28, 3 May 2006 (UTC)Reply

Simplifying management and configuration (affects both front end and back end) edit

Making mediawiki easier to use to manage a public website / Admin panel edit

Create a web user interface for administration of a typical public website using wiki content, including potentially some imported from other mediawiki open content sources. Move from using globals for config to some structured format in the database - this would enable open configuration goals like quickly moving a website between providers, making web hosting much more of a commodity market and removing exit barriers and technical barriers to those who wish to shift hosts (all they'd have to do is move their SQL dump and the whole site would appear the same). This should have an interface for extensions so that they can be admin'd too - maybe something more like tikiwiki's pages for this.

Only do basic stuff in first cut – look to FAQ and operators of wiki farms (not just for mediawiki-based services but also seedwiki and pbwiki which have some of these features). Include extension management and auto-discovery. Advanced version could include Wordpress-style theme management.

Open configuration edit

Some open configuration capabilities may make it much easier to add and remove individual boxes from large wiki farms like Wikipedia and Wikia. If many wiki farms supported these, it'd be easier to shift between providers and create a more competitive market.

It should be as easy to move between mediawiki service providers as it is to move static websites between apache providers. Providers should compete on price and service, not on their ability to put up exit barriers or technical barriers to those wanting to move.

Arbitrary apache-style and/or blog-style permissions edit

A user groups management plugin that allows administrators to add, rename, delete and change the rights of user groups (which must be defined identically to apache and/or Unix) easily. Overly complex groups management like tikiwiki supports could also be considered, but it creates as many problems as it solves. It's better to extend the apache model instead.

Some people think permissions ought to be kept minimal or not exist. But they already exist. Right now there are hard-wired distinctions between anonymous users via IP, logged-in users, sysops, developers. Making it possible to assign rights by some other criteria would help, especially those who need to match exactly an existing service or organization's permissions model, or that from another piece of software (like tikiwiki).

Expand the existing permissions model to allow fine-grained permissions based on namespaces, page name prefixes, etc. Use tikiwiki as a guide for the range of capabilities possible in the long run. Their model is at least proven, but could include many criteria specific to naming conventions used in the GFDL corpus especially Wikipedia.

Some mediawiki service providers, like wikidev.net, allow a choice between using the web server's permissions and then letting all users have equal access, or setting up multiple levels of permissions. Most intelligent users choose the more flexible and standard apache model, and avoid using the "anonymous/logged-in/sysop/developer" scheme.

Ideally a few choices could be supported:

  • classic mediawiki scheme with anons vs. logged-in vs. sysop vs. developer
  • mediawiki supporting directly the .htaccess or other W3C specified scheme (this is the way it drastically simplifies integration with conventional websites)
  • mediawiki supporting directly a blog permissions scheme from a cooperating blog host that exports it
  • a full blown CMS scheme compatible with tikiwiki (facilitating users to shift over)
  • importing an organization permissions scheme specified in XML in some way defined say in LegalXML - blue-skying here

Integrating blog and staging wikis edit

Look at wikinfo.org for a good idea of how useful mass import is... it's a project in itself to just catch up with mediawiki. There are a few projects that integrate multiple wikis for staging purposes, typically to create public web sites (see below)

or integrating it with blogs:

A list of features might include:

  • automatic propagation of changes from one wiki to a sister wiki
  • specifying regular expressions to decide which wikis to get which parts of namespace from
  • automatic linking of phrases in the blog to any pages already exist in the wiki with the same names (say by adding them at the preview stage inline or as editors' notes) including similarity checking different names and allowing edit after the fact to correct these notes (which anyone might do).


Other stuff edit

Various edit

(Temporary) !!! Need help with straightening out the incorrect subheading on TOC (table of content) of the latest new proposal: 6.38.1 should be 6.39 instead.

Wiki ID edit

See Wiki ID

MiniWiki edit

See MiniWiki (Talk:MiniWiki).

WholeEarthWiki edit

See WholeEarthWiki.

Virtual Mind edit

See Virtual Mind.

Internet think tank(s) edit

See Internet think tank(s).

Wikindex edit

See Wikindex.

Wikilinux edit

See Wikilinux

Wikilist edit

See Wikilist.

Wikigree edit

See Wikigree

Wikibill edit

See Wikibill

Wikilocal edit

See Wikilocal

Wikigene edit

See Wikigene

Whykipedia edit

See Whykipedia

WikiPoetry edit

See WikiPoets

WikiDmoz (alias Chainki) edit

See Chainki

Wikisearch edit

See Wikisearch

Wikiprograms edit

See Wikiprograms

Wikiart edit

Proposed arts review and announcement wiki, see Wikiart.

Wikumentary edit

See Wikumentary

Wikapplications edit

See Wikapplications

Wikiatlas edit

Wikiatlas would be a geographical archive of maps, monuments, cities and peoples.

Comments (not project ideas) edit

This is a thought 3/27/06 J17:02, 27 March 2006 (UTC)~~

I have a suggestion:

Perhaps you could add some type of feature that would come up with a list if an incorrectly spelled word is typed into your search.

For example, if I type in "hohobo oil", the search comes back "no results found".

If you added a line where the user could add that to a list of "commonly misspelled/mistyped words/phrases, then then the user could link that misspelled word/phrase to the correct word/phrase after they revised their search.

So, to continue my example, after figuring out that the correct spelling is "jojoba oil", I could add or "link" "hohobo oil" to jojoba oil, so then if someone else ever does a search for jojoba oil but spells/types it as hohobo oil, a page will come up asking "is this what you were looking for?" with the correct spelling.

I would be willing to help in any way possible!

I think that, if done effectively, this would increase the ease of use and broaden the audience of users, basically, make it simpler and easier to find something on Wikipedia!

Avid User

Thanks for the suggestion, but we have redirects from misspellings for that. --Gray Porpoise

Wikipedia quality review edit

Yes, I know i'm not the first to think about it...:

As we all know, the biggest wikipedia problem is the quality of the articles. So here's my ideia.

Setup a board, senate, comission, etc of known or proven scholars or specialists on diverse fields of human knowledge. these people would have the task of reviewing articles.

Then, those articles properly cleaned and review would be locked and marked with a beautifull banner saying "Quality control passed" (or something less ugly and more dramatic). The ideia is to make the article glow from afar. Kind of Featured articles but bigger still.

Is someone wishes to change the article, then those changes would be delayed until review.

Now, these scholars or professionals must be paid (the details of who, how and how much are minor)

And the money? Well, place adwords in the articles. Makes some sense doesn't? After all, it generates revenue for the foundation AND links the knowledge of the article to the rest of the world.

Well, why not ?


For one, wikipedia being reviewed by experts is almost oxy-moronic. Think about it, how could an expert review articles about popular topics (such as eminem or MJ) that are contantly changing? Experts usually review long standing topics of antiquity, and while wikipedia has many of those that may be reviewed, most is of the latter sort.--Hypergeometric2F1[a,b,c,x] 05:42, 17 December 2005 (UTC)Reply


You didn't quite get my meaning. I said *several* reviewers. Your problem could be trivially solved by adding or hiring more reviewers or editors. Plus, a topic that is constantly changing is inherently easier to review because there are less sources of new information to base a new review. Plus, experts review almost everything. You trust cnn.com, do you not? Someone approves what goes in the front page.
But you oversimplified the problem. I said that those people were to be properly paid to review the 'pedia. So, if it's too much work for X reviewers, just hire more.
Btw, your first sentence about an encyclopedia revision being 'moronic, is quite short-sighted. I'm proposing a solution for a problem, I don't need excuses for inaction.

Tg 01:23, 18 December 2005 (UTC)Reply

I said OXY-moronic. And I was referring to the idea of having wikipedia reviewed, not a revision. One question for you; what expert would review an article on the MTV show "Jackass", or the article about the term "Nerd"? Wikipedia exists because there are no "experts". Wikipedia with "experts" wouldnt be wikipedia.--Hypergeometric2F1[a,b,c,x] 06:51, 18 December 2005 (UTC)Reply
Well, I believe that a Wikipedia with experts would be a better wikipedia. In answer to your question, simply don't review all of the articles. You don't have to because I suspect that most of the cases you speak of, revision wouldn't be as important. I don't need to have articles about Eminem or Jackass reviwed. But what about an article on sexual transmited diseases? Or about H5N1? If you manage to hire an expert on virology you have on wikipedia with 500000 un-reviewed articles and 1 reviewed one.
I prety much prefer it that way.Tg 12:02, 18 December 2005 (UTC)Reply


Bring this up on the 'pedia instead. This is for entirely new projects. -- user:zanimum
Will do... but where exactly? I'm lost.. sorry -- user:tg

I think all this consense on a global scale stuff is an inferior solution. It somehow diminishes each user's freedom although that is not really necessary. Your quality assurement idea could be pretty nicely implemented by using such a thing like the WikiGlobalFS (see Proposals_for_new_projects#WikiGlobalFS). It could provide for a much more pluralistic world and would remove the 'there is only one version and we ALL must agree' thingy.--Cinquero 13:10, 8 February 2006 (UTC)Reply

I think you could do what you're suggesting without hiring anyone or sacrificing the philosophy of Wikipedia if you simply encouraged these "experts" to contribute to the pages they're experts in. User:aozeba


Wikibooks edit

Here's an idea, it's pretty radical, but I think it's necessary. If a Wikibook hasn't acquired X amount of words in Y amount of time it should be deleted. There's just too much clutter, the number of books is growing at a rate so great that if it continues unchecked will never be able to fill any of them up past the sparse text level.

Bring this up on Wikibooks. - Kookykman

Wikicorp edit

My idea is to create a wiki that would track corporations and their subsidiaries: for example if someone wants to know who owns their TV station or their telephone provider, etc.

A typical page might be structured like this:

Conglomocorp-

-Conglomotelephone
-Conglomovision
  • Wikipedia on Conglomocorp
  • www.conglomo.com

I am not willing to take responsibility for the project, its just an idea i had. I will, however, be an avid contributor if it takes off. I think it could have a structure very similar to Wikispecies, with big overarching companies like Viacom as kingdoms, and smaller subsidiaries as phyla, genera, and so on down to actual brand names or businesses like Lucky Charms or Home Depot. It could also link to information about these companies and who runs them- CEO's etc., in Wikipedia. If you like this idea or think you could be a part of it (or if you have any suggestions) please write under this post!

User: Aozeba

Open questions edit

  • Can we have a wiki forum to discuss issues?
  • The best place for multilingual links ?

possible variants:

  1. every entry in Wictionary, at the end
  • The best format for multilingual links ?

variants:

  1. Use its language letters for every word, translation to the entry language, transcription
  • The best name for multilingual links ?

variants:

  1. multilingual link
  2. translink
  3. mlingk or tlingk

please take part in the discussion

MediaWiki wiki edit

The MediaWiki information here doesn't seems to be separate from the other projects, so why not give it it's own wiki? Brianjd | Why restrict HTML? | 05:38, 2005 May 13 (UTC)

You're suggesting splitting information about the MediaWiki software off from meta.wikimedia.org? What advantage would there be to doing that? I think it would be annoying to have yet another login to deal with, and it would be confusing to add another domain and another namespace. -- Beland 13:54, 1 Jun 2005 (UTC)
Why do it? Because we currently have a non-editable page at wikipedia.sourceforge.net that looks quite different to our other pages.
Another login? Not a problem once the single user login issue is finally sorted out!
Another domain? What's mediawiki.org? Brianjd | Why restrict HTML? | 13:22, 2005 Jun 3 (UTC)

Why the Wiktionary category on the content page edit

I'm a visitor from Wiktionary, and was just wondering why the content page has a category:Wiktionary tag, when there is no mention of Wiktionary in the content page or this discussion page. "Being Brave" I'm about to remove that category tag. If you know a good reason it should be there, by all means put it back. richardb of wiktionary.

About Category edit

Hello, I am not sure where should I post such question, and I hope this is the right place. In Category views, is it possible to indicate the number of articles in each subcategories before one clicks into it? This could be a very useful construct for better organizing Categories. Thanks.--Wingchi 01:38, 13 November 2005 (UTC)Reply

At present this isn't possible, as the software does not have this feature. Bugzilla: is the place to make feature requests, and it appears that someone has already made one similar to this - see Bugzilla:3834. You can add your comments there, but Brion (one of the developers) has said it might be "unnecessarily expensive" (by which I presume he means it would use a lot of server resources for relatively little gain).
As for where you posted this question, no this isn't the right place. On the English Wikipedia I would suggest Wikipedia:Village pump. If there is an equivalent place on Meta I'm not certain where it is, but someone else will supply the link I'm sure. Don't worry about it too much though (you got an answer after all!), but note it for future reference. Thryduulf 14:17, 19 December 2005 (UTC)Reply

I have a Proposal edit

I have a proposal, but should I post it on the content page or here? Cause I'm not exactly sure what "take responsibility for it" means. Am I supposed to pay money or something? --anon

No, it simply means don't drop it here and run. Reply to questions, be willing to change the scope or structure, etc. I'm eager to hear what your idea is. -- user:zanimum

My proposal was at first a Music-Wiki, where somebody would submit lyrics and then write a description on what it is about. There would also be a description and an external link to a video of the song (if it's available). However, after I had suggested at some place, two days later, somebody proposed an idea similar to it (I hope they didn't steal it).

yes, i think a wiki-lyrics would be great. 212.244.146.101 15:05, 29 June 2006 (UTC)Reply

Later, I had thought about a Wiki-Fiction, a place where you could create stories, but I found that somebody has proposed that already.

Now, I'm thinking of having a Wiki-RPG. A place where you can pretend to be a character and act them out. I've seen other sites like that, but it would be nice to have a free one. --anon

Fiction has already been done, see Novelas' WikiStory system. You might also want to take a look at Real Life Soap Wiki. It's not quite the same as this RPG you're suggesting, but some of the ideas they've developed might serve as inspiration. While I doubt this will ever become a Foundation project the advantage of the community here is that things that don't make it can still branch out on their own (usually on Wikia), take Wikireview for example. Anyway your idea sounds very interesting... if you could draft up a little sample ruleset or paragraph or whatever of exactly what it is you're envisioning I'm sure you'll attract some potential members (besides me, I mean). Oh and you should certainly consider getting an account before you get too deep into this so others can become familiar with a definite "you". As MasterCard says, "be a name, not a number" (or, wait, is that American Express?) ...anyway, it's definitely got me thinking... :) Garrett 09:41, 6 January 2006 (UTC)Reply

Well, I'll think about getting a username. And you want an example for a WikiRPG, right? --anon

Wikisnippet proposal request for comment edit

I am willing to take responsibility for this proposal; however, I want to get initial feedback on the idea first.

It's long been established that an open wiki isn't a suitable medium for editing the code of large software projects, such as Mediawiki. These projects need strict quality assurance guidelines, check-in procedures, and accountability to prevent continuous introduction of errors and regression. I do not contest this.

However, take a look at some of these articles:

These pages are filled with short implementations ("snippets") of certain algorithms in many languages. I created the articles when I first observed that a ridiculous number of redundant implementations were being added to the articles on sort algorithms. On a few such pages, editors have aggressively moved code to Wikisource, but I don't think this or Wikipedia is really the ideal place for them.

Notice that code snippets, unlike software projects, are less susceptible to the disadvantages of a wiki. Each snippet is independent, so no change will cause large-scale failures. Snippets are often written for purposes of exposition instead of execution; although the implementations above are correct and can be run, they're intended primarily for reading.

Now, why isn't Wikipedia or Wikisource the right place for snippets? Most notably, because they have the wrong license. Document licenses like the GFDL and CC-by-sa don't deny implied warranty, which is important for code, and create some restrictions that can seem rather odd for code. We don't want a license like the GFL, which limits commercial use contrary to the Wikipedia spirit, but a widely-recognized non-copyleft license like Modified BSD would be much better. Additionally, on a wiki dedicated to code snippets, we could organise them in a more sophisticated way, placing a single snippet in each article and creating categories for algorithms, programming languages, natural language used for symbol names, and anything else we please such as in-place algorithms, quantum algorithms, and what have you. We could allow each snippet to be downloaded as a file and provide instruction pages on how to build and use snippets in certain environments. Special additional software support might provide syntax highlighting, live sandboxed compilation/interpreting of code, or other neat relevant features. We could use interwiki links to link corresponding articles on the Wikipedia using the same natural language. Likewise, we could link from the Wikipedias to suitable categories and lists on the new snippet wiki.

This is my concept of Wikisnippet. What do you guys think? I'll write it up if there seems to be some approval. Deco 23:06, 28 December 2005 (UTC)Reply

Well, after two weeks with no comment, I'll see if I can take this to Wikia first. Deco 21:36, 17 January 2006 (UTC)Reply
Sorry, but Wikia is GFDL, so this can't go there. For GFDL-compatible code, there's a programming wiki. Angela 15:27, 19 January 2006 (UTC)Reply

smart boy:-hey guys, i want to suggest that all the information of wikipedia should be saved in a set of dvd's which should be sold to public for some profit or on no profit no loss basis . this would help people with low internet speed .whats your opinion on this proposal.ok bye

University challenge edit

I propose putting forward a wikipedia university challenge team. How about the BBC putting you up against brittanica?

Proposal: WIki Guitar edit

I run a site at http://www.wikiguitar.net

I suppose this isn't really a proposal is it then? How does everyone feel about my site though? - THe idea.

You should probably be aware that all the tabs on your site violate copyright - remember what happened to lyrics.ch. No site that relies on massive blatant copyright violation for all its content can hope to survive indefinitely. Deco 03:43, 14 January 2006 (UTC)Reply

Proposal: WikiHowTo edit

To read old discussions visit: http://en.howto.wikia.com/wiki/Wikihowto/Site_move
News
  • WikiHowTo, Wikisolutions, and wikia have joined as one site
    http://en.howto.wikia.com/
    • We are currently working on finalizing policy and creating good examples of Howto's and Guides.
  • WikiHowTo is really coming together. It now has over 100 howtos, 15 guides, and over a hundred objects. Most policies are worked out, and is getting close to becoming practical.
We need help in many areas, if anyone is interested, come and check it out
Opinions?

.

Has this been proposed before? edit

I was thinkins It would be nice to create a 'wikilyrics' proyect. The name is preaty (how is that word spelled? I have no idea) much self explenatory. People would post lyrics from any and every song there is. Maybe this could be incorporated with other proyects (like wikimusic for example). nnfolz

Again, remember what happened to lyrics.ch. No site that relies on massive blatant copyright violation for all its content can hope to survive indefinitely, and almost all popular music lyrics will be copyrighted by record labels for at least a century. Existing websites which do this only pull it off because they're too numerous and unimportant to sue individually. I can guarantee that Wikimedia will not pursue such a project - they have focused on free content since the beginning. Deco 03:43, 14 January 2006 (UTC)Reply
Wow. I was not aware of that. But there is one thing I don't get and maybe you guys can help me out: How is posting lyrics on the internet is copyright infringment? I mean we are just posting the lyrics and not providing the song itself for download. nnfolz
There are different copyrights for different parts of the music. A Karaoke-service will need to have separate license for the music, the video and the lyrics. (Been there tried that)
You know, I thought of a Wiki-Lyrics before, too! --anon
If it wasn't such a problem with copyrights I would greatly support this project. I thought of a wiki for movie and tv series transcripts but those are also copyrighted. --IRbaboon

ArguWiki edit

Having joined several discussion forums I have grown quite tired of starting the same discussion all over from scratch every time someone new joins. It makes the world go in circles, and progress is difficult.

My idea would be to have a wiki where one could post only a list of the different arguments for and against. These could again contain a list of arguments for and against. The point should be just to show the possible views of the case, not to make any conclusion.

That way all arguments would be heard, and be viewed toghether with counter arguments. People would be enlightened also about views that are not to popular. By suppressing arguments they may get their own underground life and gain supporters without ever having been put in the critical light of educated people.

Challenges: - How to display this. What argument is for and what is against is not always obvious, it may count both ways. (I.E "The rich get richer", which is a pro-argument for the rich but a con-argument for the poor) - How to relate arguments. Having the details of a counter argument on another page, may make it difficult to keep arguments related. - How to keep the list clear and concise. It is not easy to describe even a link to a counter argument in few words - What is an obvious stupid argument. The argument that Santa is in danger because of air traffic, may be stupid and could be removed. It could also be met with a counter argument that he doesn't exist, which may trigger a new ray of arguments.

Basically this is just an idea. Maybe it will be possible, but I see that it may be difficult.

The idea is kind of nice but I do not believe this is the place for that. Arguments are to subjective and one argument often leads to many. If you wanted to syntethize arguments about a certain topis why not put them in a wikipedia article, something like this: http://en.wikipedia.org/wiki/Omnipotence_paradox
In that article arguments are presented from many points of view. Where you interested in a especific topic? What is the subject of the discuccion forums you visit frequently? Maybe you can start an article in the subject (or edit the curent one if it already exist). nnfolz
I didn't have any particular topic in mind, but was fascinated by the vague idea of collecting what you may call the essense of the debate for different topics. I don't disagree in putting the elaboration of every argument in an article, but this would be designed to show what arguments (normally) used in a debate to show that things are not black and white, and maybe lead people to further reading. I may sound a bit dumb saying that articles have to much text, but basically that is what I mean. A kind of hierarky to help people find the knowledge that is already on the Internet. Gathering only the keyword/link may also give a different overview of the core and complexity of the discussion.
    • I think this is a great idea. you could go point for point. so someone could look up "Man on the moon: (or something) and get an Idea from the main page of what arguements exist about the issue: "truth" would be the main arguement. but some issues would have things like "moral", "economical", "social", "foreign relations" ect ect. each with a sum of what the arguments are. These could lead to sub-pages that would break down point for point argument and counter arguement. One side could say "man couldnt have travelled through that radiation belt around the earth (kupiers belt?.... its not important)" the other side would counter that point with arguements about that point only. That way we dont get these long rambling repetetive non proffesional arguments you see on discussion boards. You get a nice debate.

And the point wont be to argue and win but to help people get an idea of the differant sides of an issue. Of course the obvious problem is that things will get heated.... VERY heated on some sights. and since one could just as easily edit their own arguements they can edit the opposing arguements(can't beat em, delete em) it would lead to complex civil wars. we should do it anyways.--Olsdude 01:31, 21 January 2006 (UTC)Reply

Hello: such a wiki has already been created at http://pov.wikia.com. I would be very happy to have more people join. Danny 19:21, 21 January 2006 (UTC)Reply

Wikitopia: I recentley had an idea conserning issues and current events which I believe relates to the above. The idea is simple, you'd have a page containing a list of issues. The most active issues sit at the top of the page. You can then go down the list to less and less active issues and jump through them like search results. On the a page for an issue people can post FACTS relating to that issue. This would help anyone trying to decide on an issue, understand all of the facts before making a decision. The most active issues, will obviously be the issues people feel most strongly about, and will be willing to do research to back up. US Congress as I understand it, currently does this with the issues it presents. It doesn't however, have the access to people across the world doing their research for them. This could be used to help solve tons of issues using FACTS, from abortion to world hunger.

This wikispaces name is already taken. Visit arguwiki.wikispaces.com.

WikiFiction edit

Has this been created yet? Also, is the WikiCity free? --anon

I like this idea. I was thining something similarly today. Can we make a first Wiki Book? Start with a basic outline of a story and write what you can asking user to add to the story and rework what you have written to fit in with your style and structure, You being the user who comes across the work and adds to it. Because Wikipedia saves all changes others could pick up old versions of stories that best suit them. If we applie data strings or search features for the story we can find a more appropriate time line for the book. It to me is very Quantom, or at least how i see quantom mechanics to be; Each unit of time asking yes and no and based on that yes no answer a new universe is formed where that no answer impacted a larger yes universe and so on. I think that it would make an awsome organic book project. We could also perhaps further the idea by stating an upward end to the amount of users per project Or chapters per project. If you had 6 users you have alot of combinations based on exponential growth and idea discepency. if you have 100 users you have that many more possibilities for said outcome.

--Phillipeb 00:49, 17 April 2006 (UTC)Reply

WikiRecipe edit

I thought it would be neet to have a wiki where users could submit their recipes.Cannonstudent 20:00, 11 February 2006 (UTC)Reply

That sounds like a nice idea! Are there any restrictions? --anon

There's a wikibook cookbook I think.

I wouldnt mind seeing a wiki cook book that would ask you the basic ingredients you would like to have in a dish or have on hand, thus finding a match that most closely resembles that query. I rember there use to be an aim bot that would do something similar but it was notoriously unreliable.--Phillipeb 00:50, 17 April 2006 (UTC)Reply

I like the idea; maybe a split off of Wikibooks. --Gray Porpoise 23:47, 23 August 2006 (UTC)Reply

Familly tree wiki edit

I know there have been quite a few attempts at familly tree wikis. I was wondering what the Wikimedia communtiy thought of this one. It has been customised for ease of use with geanological data (see the English Main Page for more. I am not the actual creator of the site (he is User:Baya on the site). The current liscense is CC-BY, not GFDL as familly trees are mostly factual data anyway (which can't be copyrighted). If it was really necessary I think it could be reliscenced under the GFDL.--w:User:Bjwebb, [1]

I now have a meta account.--Bjwebb 11:14, 21 February 2006 (UTC)Reply

I think it would be a good idea: eventually everyone could be linked together! ~ Trisreed my talk my contribs

WikiLab? edit

Hi

An idea that I've been considering is whether Wiki technology could be used to create a place for collabrative 'mass' science experiments...

Such experiments would be at a 'kitchen' level or just above, making them reasonably suitable for all.

Some examples of experiments a WikiLab could do are:-

- A rainfall acidity test - A Global temprature survey (by collating results from many sources)


Shakespeare Fan00 62.56.44.20 01:28, 5 March 2006 (UTC)Reply

WikiSymptoms? edit

There is a lot of health information on Wikipedia so why not take it a step furthur and create a wiki dedicated to symptoms and what they mean? - 71.126.150.183 01:20, 8 March 2006 (UTC)Reply

Suggestion: E-mail This Article Feature edit

I would like to suggest that an "E-mail This Article" feature be added to the Toolbox to encourage the sharing of information between friends, family, and colleagues be better enabled directly through the Wikipedia interface.


Wikibabel edit

I'd like to suggest to create a Wiki where one can practise new languages during a course or study either in their home countries or at home or ... just anywhere. If some known bilingual experts are willing to support people who want to learn a new language, it can be a cheap, accessible and easy way to exchange knowledge. The main advantage will be that people speaking e.g. German who learn e.g. Spanish have the same difficulties, I presume, and are able to learn from each other's mistakes (which are mostly similar, I think). It'll be a very practical way, I think, to improve your skills and fluency very quickly, in meeting (online) with people whose native language you are learning!

It will be no surprise, I think, that Unesco will be very supportive of this idea, I think.

Sally Mens alias Verrekijker
Utrecht (Netherlands)
Verrekijker 22:27, 28 March 2006 (UTC)Reply

This proposal is slightly different from Wikibabel, elsewhere on this Meta:Wikimedia. It also differs from Wikilingua. Verrekijker 23:02, 28 March 2006 (UTC)Reply

Well, you could practise them on Wikipedia, and just create a WikiProject so that people can support each other.--Bjwebb 12:36, 31 March 2006 (UTC)Reply

Thanx, I'll download Wiki. Alas I can't find a handbook on dealing with it technically online. Do you know if there's one available somewhere?

Dutch Wikimedia Foundation (esp. Henna and Galwaygirl) know about my initiative, for which I hope to get funds from Dutch-Flemish language organisation Nederlandse Taalunie.

What about setting up language study groups (or materials about learning languages) in Wikiversity? It shouldn't be too long before this project gets underway, and it doesn't require any downloading of wiki software. In fact, I don't think that's what the suggestion of a WikiProject was - this is just a project within a project (such as Wikipedia, Wikibooks etc), as far as I use the term. Cormaggio @ 23:03, 2 April 2006 (UTC)Reply

That'll be fine but not sufficient. What's needed is a low profile possibility to practice a language, or just something to translate some quotes. If daily practisers or experts, known to translating into the tongue of the questionner, are helping, it's a known fact they know more about the translation-idiom than can be extracted uneasily from language course books. Verrekijker 23:08, 12 May 2006 (UTC)Reply

future updating proposals edit

article transclution edit

Would it be possible to, like in links, beable to transclude just a subsection of a article? It would look like this: {{:example article#example subsection}}

Clean-up attempt in progress!! edit

I think that the content page as well as this talk page deserves a well intentioned scrub down. Let me know if I step on any toes :) Robert Harrison 06:38, 1 April 2006 (UTC)Reply

Geneological Websites edit

(Note: This is discussion that was on the top of the main page that really should have been put here instead. --Roberth 14:12, 1 April 2006 (UTC))Reply

*Important - I had an idea a couple of months ago regarding a family-tree-wiki, or wikigenea, or something will be the most used.--Bjwebb 11:07, 27 March 2006 (UTC)*Important - I had an idea a couple of months ago regarding a family-tree-wiki, or wikigenea, or something similar, but discovered here at least 3 that were already operational - http://genealogy.wikicities.com, http://en.rodovid.org, and http://www.wikitree.org. I'm not sure which of the three is part of the wikimedia foundation, but couldn't it have a main link along with wikipedia, wiktionary, wikisource, wikispecies, etc? Until yesterday, I had no idea that such a thing existed - they really aren't well advertised.Reply

Also, I think that the three, if possible, should either be reduced to one (if everybody involved agreed) or collaborated together, and quickly - we could end up with three useful family trees, but with different people adding to different ones rather than all working together and coming up with a larger and more useful family tree. Saccerzd 17:59, 26 March 2006 (UTC)Reply

None of those projects are part of hte foundation, yet there are already merging discussions between Rodovid and Wikitree. As for the genealogy wikicity, it doesn't seem to be doing much, but I've added a comment to their site anyway.--Bjwebb 18:22, 26 March 2006 (UTC)Reply
    • Couldn't the wikimedia foundation establish their own geneaWiki or wikiTree? I think that due to the high profile of wikimedia, it would quickly become the most used. Saccerzd 09:26, 27 March 2006 (UTC)Reply
      • Well, Rodovid is trying to be incorporated as a foundation project. If this happens, then yes, you are right, it s trying to be incorporated as a foundation project. If this happens, then yes, you are right, it will be the most used.--Bjwebb 11:07, 27 March 2006 (UTC)Reply

Wikimorial edit

Should Wikimorial be listed here so people know it's been proposed? 24.18.215.132 21:25, 8 April 2006 (UTC)Reply

WikiEpisode edit

After reading some of the discussions on just how appropriate TV show episode guides are for an encyclopeida or not, I thought I'd make this suggestion. Maybe a project which is specifically a repository for episode guides? This gives them a place (I think they are very valuable information), yet be out of the encyclopedic realm of Wikipedia itself. Wikipedia articles would still be able to reference the lists as a whole or specific episodes as needed for encyclopedic articles. Any thoughts? BladeHamilton 23:03, 13 April 2006 (UTC)Reply

A good idea actually. Very nice. --Alfakim 04:26, 22 May 2006 (UTC)Reply

Wikipedia and AI edit

I was thinking having read this article and followed Wikipedia for some time now that it would be great to have a project that was equal parts A.I. As well as Wiki. I think that if a computer could learn algorithmically how a single person comes up with an idea based of fact and how a community organizes that thought based on established hierarchical order, we could go along way in programming a smarter artificial intelligence. Also if we use the Wiki format the actual code to be written could be a collaborative effort as well making this artificial intelligence a sort of conscious, collective unconscious.

Phillipe Bojorquez --Phillipeb 00:40, 17 April 2006

Related initiative may be considering a new approach to automatic acquision and application of "common sense knowledge" and integrating such an "engine" into Wiki. If something like this could be made to work with reasonable "relevance" then Wiki could start adding topics and draft content from on-line content (sort of as search engines, but with a different purpose)- all subject to human review and extensive edit. Professor Doug Lenat's "Cyc" projct comes to mind. Claims/objectives for OpnCyc are listed on [2].
A much more modest first initiative would be to include an "automatic summarizer" option for human written content on Wiki.
Perhaps Google could fund such open R&D efforts, since they are related to its business.


LPfeffer April 22, 2006

WikiTools edit

For authors it would be useful to have integrated into the Wiki's editor a few basic tools like:

a) spell checkers

b) language tools like Google has (e.g. for rough machine translation between a growing set of languages)

c) link suggestor - e.g. to take a paragraph or a whole document and suggest possible links to existing content in Wiki or other on-line content. A parameter would limit verbosity. If a documeent already includes links then an option would enable automatic inheritance of relevant links by a new section in edit mode - to be reviewed and edited by the author

d) notifier to automatically notify an author of any changes to all or selected pages she/he added content to -- also available to readers

e) etc.

For all users it would also be useful to have:

a) phonetic search

b) basic visualization tools - e.g. historic graph of Wiki page growth

c) author search - search for all Wiki pages marked as authored/edited by one or more authors (in various contexts: all contexts, content page only, discussion only, etc.)

d) etc.

LPfeffer April 22, 2006

This is not so much a project as an extension to the software of existing project. I believe MediaWiki is very ready for such forms of expansion - see MediaWiki extensions or suggest features to be added to the the core of the software at Bugzilla. w:User:Bigbluefish

WikiTestimonies edit

This would be a very important new capabiity for communities of interest to be able to gather and diffuse testimonies, sort of like the Yad Vashem Holocaust museum in Jerusalem archive on Holocaust victims and survivor experiences. There is a glaring need for a similar but self-running Testimony Archive for the Gulag and other democides/genocides, for natural and man-made disasters like the recent Tsunami in the Far-East and September 11, and also for less traumatic an even enjoyabe community experiences.

The basic mechanism would be based on a structured Testimony Form designed by a community gathering testimonies. The form would feed data into a database and various summarizers and cross correlators would be available.

The community and others could then annotate the aggregate collection and specific testimonies.

There would be room for images and audio.

This project would radically expand on-line storage requirements, especially for large communities like Gulag survivors and relatives of victims and survivors, etc.


LPfeffer April 22, 2006

My opinion: testimonies only have integrity if they're reproduced as testified, as opposed to summarised or copy-edited by others. As such a wiki format is an unnecessary if not inappropriate format to use. You want something capable of better structured organisation of the information, and which makes firsthand authorship more guaranteeable. w:user:Bigbluefish

WikiResearch edit

This could be a very usefull idea here (it may require some additional software)

Here's the proposition: a wiki that would be dedicated to statistics, polls, studies, and research. I've seen a few ideas like this, but this one seems to be inclusive of all of them. It might need some poll funcitionallity (hence the 'additional software' comment) but other than that, I think it would be very useful. People could cite wikiResearch articles in their articles to get up to date data from all around the world.

Wiki Activism edit

Hello! - my name is Nickolas am "willing to take responsibility" for this project, but I don't feel that this description/proposal is ready to go on the actual Proposals for new projects page. I'm new at the project proposals game, so I would really appreciate help, advice, or constructive criticism. Actually, even hateful, unconstructive criticism could help let me know where I go wrong (ha ha).

The Idea:

WikiActivism is a project for past and present social movements such as the Civil Rights movement, Animal Rights movement, and the blooming Immigrant Rights movement. The meat and potatoes of the project will be a page for each separate movement. The majority of pages (great in number, though less important than the main page for each movement) will list evidence used by or against each movement, organizations associated with each movement, and other such items. (Most links on each page will probably go to Wikipedia for explanation of various terms and issues.)

How is this different than the existing pages on Wikipedia?

  • It will be more in-depth than the Wikipedia articles. This will include:
    • Evidence and statistics cited for or against movements
    • Organizations associated with movements
    • Detailed mapping of the inter-relations between movements
    • A deeper consideration of the issues of the movement
  • There will be sections devoted to the ongoing activity of each movement (almost like melding Wikipedia with Wikinews for these movements).
  • Each movement will have a page or pages describing practical actions that potential movement members or supporters can take to further the movement

Issues, Concerns, Objections and Questions:

Many of the concepts and ideas on the pages have explanations on Wikipedia, and would be unnecessary (and maybe against copyright) to copy over content from the 'pedia to this project. Is it considered bad form for many of the links on a particular project to actually lead off to other projects? Or is that considered necessary? I notice that Wikibooks has a lot of that, so I guess it's okay.

It is possible that this project will not fall under the WikiMedia Foundation charter, which is to spread information. This project is meant to spread information, but is also meant to have practical information on how to contribute to various movements. Is that okay? Please opine.

To me This sounds like something that would be more at wikicities, but I'm not that informed about this process so I don't know whats for wikicities and whats not, very much. It certainly sounds like an intreasting idea. You can copy stuff from wikipedia to your wiki if your is under GFDL (or compatible) license (have to give credit though). Projects seem to have different policies on inter-wiki links. In wikinews: almost all links in an article are interwiki (besides sources and releated), where as in wikipedia: to me it seems to ussually be bad form to use inter-wiki links except for thoose boxes in external links. (althugh I'm not very active at wikipedia so I don't know that). Bawolff 01:27, 20 May 2006 (UTC)Reply
Check out wikiasite:activism, and also have a look at wikia:List of Wikia in case there's others that overlap - you may be able to do it at the existing wikia, or at least discuss it with like-minded people there. --Singkong2005 05:49, 29 May 2006 (UTC)Reply
I'm trying to get such things started on wikireason.org, which is currently looking for a new hosting solution due to growing traffic. -- Beland 03:58, 4 June 2006 (UTC)Reply


Nickolas--no contact information? I've been working on a very similar project which I've been calling WikiCitizens. I posted a description on the "proposals for new projects" page. I also submitted a proposal to launch a version of WikiCitizens at wikia.com. I've seen many projects that are similar, but none of them have been quite what I have in mind. Your idea sounds the closest to the kind of community I eventually want WikiCitizens to become. Perhaps we can talk more? --ejmasicampo

Image tools edit

Hi. flickr.com have a very hand feature where you can specify areas of an image with a box. Hovering over them shows a description, and all the boxes can be hidden to give a unobstructed view of the image.

I can think of 2 good uses for a tool based on this idea:

1. To point out of locations, landmarks, or objects in a photo without covering the photo in references.
2. Better functionality and consistancy for images that are already used mainly for references (numbers, letters, refered to in captions, or the lines leading to words in the image etc.).

-- Justin[[3]]

Adding a rate counter to the home page edit

I think it could be somehow impressive to see an annual rate of growth next to the number of total articles on the home page. Something like (for the English edition): # of articles 1,200,000 and currently growing at 8.5% annual rate... On a second thought, I am realizing that it's not an exponential growth, i.e. the rate is probably decreasing. Still, it might be interesting. Mike.

Given those figures, I assume you're talking specifically about Wikipedia. While we don't have it on the front page, you can see the annual rate of growth at en:Wikipedia:Multilingual statistics. For en: it's a healthy 102%, and for Wikipedia overall, it's 132%. Warofdreams 02:08, 6 June 2006 (UTC)Reply
It'd be cool to have an updating counter like Spread firefox had for downloads ( http://ed.agadak.net/greasemonkey/ffCounter/ffCounter.php but doesn't seem to work anymore)

WikiPoll edit

Check out WikiPoll, thanks --81.57.3.212 16:26, 26 May 2006 (UTC)Reply

The format of this page edit

I find it very hard to use these pages. I don't even know how to begin improving these pages because "proposals for new projects" doesn't have a real "talk" page. Instead, this page is used as a "secondary" proposals for new projects.

Where are we supposed to discuss the content and layout of "proposals for new projects"?

I propose, that we split "proposals for new projects" up into a series of pages:

  1. Instructions for proposing new projects
  2. Projects that you should look at before making a proposal
  3. Serious proposals for new projects
  4. Brainstorming for new projects (inactive proposals)

How does that sound? AdamRetchless 19:54, 29 May 2006 (UTC)Reply

Sounds good! User: Aozeba

I have a Proposal edit

has there every been a discussion about having a wikimemorial project. Many people try to create article about people that were important to them and their community but who do not belong in wikipedia. Wouldnt it a project for memorials be a good thing, it could expand knowledge of lessor known citizen and thier accomplishments. I understand the difficulty in such a project but just because something is difficult doesnt mean it isn't worth doing.kev62nesl --199.232.72.123 21:40, 6 June 2006 (UTC)Reply

How do we guarantee that every entry is correct, and not slanderous towards someone who can't defend themselves? -- Zanimum 15:36, 9 June 2006 (UTC)Reply


WIKI INTERNET SEARCH ENGINE edit

This is incredibly ambitious project but I wanted to raise the idea of using wiki style software to create a far more logical and uncorrupt search engine for navigating the Internet. I believe that if wikipedias method of conscious self-organization from the bottom-up were to be applied to a search engine the internet would be made far less of a tangled web.


Wikiography edit

Although Wikipedia contains biographies, a separate entity might be useful but I don't find any such in any Wikimedia lists. The basis is the same as the original Wikimedia elements of Wikipedia being a free online encyclopedia like Britannica et al or the Wiktionary serving as sort of a free version of the OED.

One of the best protected, but useful things is "Who's Who" and the possibility of having access to that information without the hoops/costs of subscribing thereto seems interesting???

Perhaps a better title would be "Wikiwho"?

Love.

Wikiquestion edit

There should be a wiki where people type in a question, and people try to answer it, and maybe even come up with a few ides eg. I type in "How do you dance?", a reply comes in saying "Wave your arms up and down and spin in a circle.". Then there's another reply saying "Move your feet left and right." That way, I could get many ides of how to dance, and people could come up with more ideas from the replys...

Sounds like Wikipedia's reference Desk 62.56.68.159 21:15, 1 September 2006 (UTC)Reply

history of world in maps edit

  • possible use-cases:

1) user will choose today's date - will see world's actual map and can choose own detail (zoom) 2) user will choose 1939-1945 date range and will see animated history of WWII borders

  • maps should have link(s) to wikipedia articles (and they back to maps in concrete date (date range) and detail)

solution should be 2D or maybe 3D (compare http://maps.google.com with http://earth.google.com (commercial map projects)) and will have two parts: 1) general (empty) history-maps engine (i prefer vector (= not bitmap) data version) 2) filling it by concrete data

  • notes:

- in fact already big step should be user can see map of concrete day as a bitmap (= no or minimal specific engine development) - i found just partial solutions like: http://www.loyno.edu/~seduffy/maps.html http://www.bartleby.com/67/europe02.html http://users.erols.com/mwhite28/austhung.htm - probably should have some support for disputed territories (today's examples: china-india, china-taiwan, ...) or user's comments like modified maps under history articles - there already exists open source 3d engine http://worldwind.arc.nasa.gov (question how usable is for such project)

  • yours t! (tblazko@pobox.sk) july-sept 2006
  • I am a historian and i have been looking at history atlases since i was ten years old. I have made the map for Lucius Paullus. I would be prepared to spend lots of time in this project, if i can find other enthusiastic participants.--Daan 16:52, 17 October 2006 (UTC)Reply

A Mozilla Firefox Toolbar edit

It just seems to make sense to me, and maybe this has already been done, but I can't seem to find any mention of anything like it. Could somebody make a Wikipedia search toolbar for Firefox. I use this site all the time and it would be infinitely easier to just have a little bar with which I can just punch in a word as I read it off the website I'm looking at. Also the ability to highlight a word and then right-click and get an option to search wikipedia for it in a new tab or window would be awesome. I don't know much about web applets or browser plug-ins, but I can't imagine this would take more than a week to put together.

You can get Wikipedia search as one of the many different search plugins for the box to the right of the URL box. Daniel () Check out Wikiscope! 07:42, 2 September 2006 (UTC)Reply

No response edit

I recently proposed a new project, but I have recieved no agreements, disagreements, or any kind of comments. If anyone would like to help this, please comment (even if you are disagreeing with the proposal, its still appreciating) please see Proposals for new projects#WikiShop, cheers Minun Spiderman 15:21, 5 September 2006 (UTC)Reply

Belarusian edit

Why is there a test Wikipedia for Belarusian at incubator:Test-WP/be when there is already a Belarusian Wikipedia at be: and has been for more than two years? Angr 10:27, 8 September 2006 (UTC)Reply

Griko edit

I propose a project about the creation of a Griko wikipedia. This language is spoken by 20.000 people and i can speak with some people if they want to collaborate to it. 1204grandine 21.29, 3 October 2006 (UTC)

Random aside: Shesaurus edit

The Shesaurus: Pop Culture's gender-based resource guide to Women.

The Shesaurus is America's first Dictionary/Thesaurus. Complete with over 1500 terms and illustrations, The Shesaurus includes Yiddish slang, Hip Hop, British, Irish, Jamaican and good old American slang.

Written by screenwriter and magazine publisher, Keshia Kola/Marquisha Gatewood. The Shesaurus offers hilarious anecdotes to idioms used to characterize women. Many phrases from Emmy award winning series, "Sex and the City," and "Desperate Housewives" have been popularized the book.

For more information on The Shesaurus visit www.shesaurus.com

WikiPorn.org did exist for a while twice as a succesful independent entity. edit

This project has become a reality not once but twice as a separate independent entity from Wikimedia and in both cases it has been deleted by outside sources. As in outside of the creator of the domain who both times had paid in full for the domain and server only to be nullified by the PTB even when the servers in question host adult content. Go figure that one out...

Anyhow at this point in time no Wiki containing adult material or subjects of any kind worth a damn exist anymore. That is a given. Much to the delight of of probably many here Oh well...

Return to "Proposals for new projects/Archive 1" page.