Wikipedia4 timeline (proposal)
This page is kept for historical interest. Any policies mentioned may be obsolete. If you want to revive the topic, you can use the talk page or start a discussion on the community forum. |
A Wikipedia4 timeline should include the following considerations and options. If you have an alternative approach, create a new top level item to represent the choice and the time it should be made, making the existing option and your own option two subitems under that choice. Keep this file as much as possible in en:time/issue/position/argument/evidence/source/authority format. Use wherever possible links to Wikipedia itself and fill out its articles on development to make your point. Try to stick to terminology appropriate to en:component software.
We should avoid development work until Wikipedia3 is free of dependencies on the wikipedia domains, sysops, editors, etc., and has been fully implemented in at least one other project (end of 2003?). Relatively slow development until that is satisfied (early 2004?), with the following preparations made in 03:
- Wikipedia board briefings prepared for all difficult requirements decisions that must be made prior to release of Wikipedia4, so that they can be either made by the board, or explained thoroughly to the board if they must be made in advance or without its involvement.
- transition from present Wikipedia Governance to formal governance - under whatever model - general control of Wikipedia4 by the new board, while Wikipedia3 is produced by the original informal development process/people/Dictator in place now. This should be done by recruiting at least four or five of the ideal Wikipedia board to meet with the current developers and establish trust, common positions, and dissents, to come back and document for online collaboration.
- choice of development platforms, configuration options, languages, etc.., in general compatible with those of Wikipedia3 but perhaps more reliance on standards, e.g. XML, IEEE en:foundation ontology, etc..
Early technical problems, which may be reasonable to address in Wikipedia3 but will definitely have to be resolved before Wikipedia4 gets under way:
- Spacetime DTD building on a prior (US DoD GPS?) spacetime DTD with the necessary extensions and conversions required to handle problems of history dating back 12,000 years, problems of geography and geology back potentially billions of years. Setting a global standard for terrestrial coordinates useful in most specialities where these matter.
- outreach to projects organizing geographic information, coordination with Wikipediatlas, GPS, 'smart mobs' work, to standardize spacetime_DTD, and to ensure that Wikipedia information integrates smoothly with queries using those facilities - this consideration includes PDA, Cell-phone, laptop user interface and mobile access issues.
- other considerations relevant to low-bandwidth (i.e. 24-56kbps), small-browser, mobile access to facts and maps. FAQ generation based on Access to usage logs
- Wikitax modified only according to the simple ideology of Wikitax, incorporating simplest email, IM, blog features, and implemented in stages.
- Wikipedia DTD (codifying Wikipedia3 syntax) extended minimally to help article authors correctly represent spacetime, persons' names, and ecoregional coordinates, e.g. "en:Sahara Desert", permitting compilation of all references - requires both spacetime DTD and dependent person DTD, so a pre-requisite for implementation is integrating these fully with the other DTDs.
Main/middle development problems, when there's no longer any work on Wikipedia3:
- those features impractical for Wikipedia4 deferred off to Wikipedia5 - as early as possible to avoid diluting effort, and 'en:kitchen sink syndrome'
- reconciliation of features proposed with best cases sought by contributors - how desirable is each feature?
- assessment of cost and complexity of features, difficulty of integration - how costly is it, e.g. in en:function points?
- scheduled board meetings to make decisions in advance of major developer effort, and enable dissenting positions to be laid out thoroughly and interfaces and development forks negotiated, for those who don't share board's priorities.
- funding requirements for specialist labor not available from volunteers
Development endgame:
- choosing and recruiting volunteers and specialists funded by board approval
- documentation of features so that Wikipedia3 servers can begin to use Wikipedia4 immediately - including installation instructions and hardware recommendations per size of project.
- aiming for release by end of 2004, general discipline of one release/year, so that release number "3", "4", matches year in which development takes place.
Followup:
- Bug tracking automated in wikipedia4 interface, and requirements issues and new features solicited directly from users into wikipedia5 request structure for rapid classification.
- New releases and patches propagated to wikipedia4 servers in an automated fashion, where requested, but not installed until sysops indicate their approval. Robust backouts so that servers having problems can roll back without risk to their databases or interruptions of service.