Last modified: 2014-11-20 09:10:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1 - (documentation) Documentation is out of date, incomplete (tracking)
(documentation)
Documentation is out of date, incomplete (tracking)
Status: NEW
Product: MediaWiki
Classification: Unclassified
Documentation (Other open bugs)
unspecified
All All
: Normal normal with 18 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://www.mediawiki.org/wiki/Documen...
: tracking
: 3189 7947 20000 (view as bug list)
Depends on: 19044 25998 26674 26746 27306 27650 28542 28660 29936 32892 34962 35234 38662 ve-api 38874 41956 42723 42862 42893 43591 44212 44584 45601 45745 46526 46563 46878 47113 48192 48216 48452 49989 50107 50514 50917 51629 51651 52026 52401 54701 54702 55692 55946 55997 56368 56621 56860 56864 57801 57841 58361 58498 58922 59713 60464 60587 60793 61837 62426 62446 62806 62807 62808 62809 62810 62946 63033 64813 pwbdoc 64996 65270 65794 67167 67183 67490 67938 68632 68745 68748 69287 69449 69499 70162 72163 72275 72732 73603 7 373 2377 3175 3306 6353 8629 8813 11102 12410 15475 17961 19175 21208 21511 25408 26206 26905 27215 28584 29143 29265 29768 30183 31005 31346 31750 32919 32970 33346 33524 33637 33827 34965 35403 35467 36437 36609 36757 37151 37803 37805 37896 37943 37977 39125 39349 39979 40762 40937 41378 42001 42293 42518 42687 42892 43804 43905 44127 44211 44374 44719 44904 44913 45910 45965 47486 47541 48244 48337 48492 48724 49843 50319 50552 50674 50858 51503 52006 52068 52150 52637 53716 53765 54364 54601 54890 55723 55744 55862 55928 55956 56186 56192 56204 56980 57317 58782 58994 59956 60192 60195 60462 60557 60567 60719 61322 61412 61500 61886 62179 62452 63351 63392 63674 65035 66406 66603 66934 68741 69372 69975 70633 71250 71856 71892
Blocks: code_quality tracking
  Show dependency treegraph
 
Reported: 2004-08-10 08:24 UTC by Brion Vibber
Modified: 2014-11-20 09:10 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
A patch for version.php relating to documentation (see comment #6) (813 bytes, patch)
2004-09-30 22:50 UTC, Jamie Bliss
Details
Patch for \maintenance\convertUtf8.php relating to documentation (see comment #6) (764 bytes, patch)
2004-09-30 22:59 UTC, Jamie Bliss
Details
Patch for /includes/SpecialData.php (559 bytes, patch)
2004-09-30 23:02 UTC, Jamie Bliss
Details
Patch for /includes/ZhConversion.php (755 bytes, patch)
2004-09-30 23:03 UTC, Jamie Bliss
Details
diff to docs/skin.doc to describe how to start creating or modifying a skin (828 bytes, patch)
2004-10-18 01:45 UTC, Andrew Moore
Details

Description Brion Vibber 2004-08-10 08:24:26 UTC
Our docs are teh suck. Fix them up.
Comment 1 Brion Vibber 2004-08-10 09:06:44 UTC
Need to adjust docs in the distribution tarball, and also the web site docs.
Comment 2 xmlizer 2004-08-10 16:46:34 UTC
add dependency
Comment 3 Aaron Peterson 2004-08-31 13:30:58 UTC
I see that meta's Help:Contents has an effort to templateise (?) the help
system, and make it exportable.


Is there a plain text wikimarkup renderer? so we can just export a few wiki
pages into plain text and have it automatically be included in the next tarball?
Comment 4 Antoine "hashar" Musso (WMF) 2004-09-03 23:25:15 UTC
Source code comments got moved to phpdocumentor format by myself.

The result can be seen at:
http://wikipedia.sourceforge.net/mwdoc/

It currently just provide a skeleton, we have to comment source code now !
Comment 5 Jamie Bliss 2004-09-30 22:50:06 UTC
Created attachment 56 [details]
A patch for version.php relating to documentation (see comment #6)
Comment 6 Jamie Bliss 2004-09-30 22:51:46 UTC
The patch I uploaded should take care of the 4 files remaining in the default module. 
(/maintenance/convertUtf8.php, /includes/SpecialData.php, /Version.php, 
and /includes/ZhConversion.php)
Comment 7 Jamie Bliss 2004-09-30 22:59:20 UTC
Created attachment 57 [details]
Patch for \maintenance\convertUtf8.php relating to documentation (see comment #6)
Comment 8 Jamie Bliss 2004-09-30 23:02:50 UTC
Created attachment 58 [details]
Patch for /includes/SpecialData.php
Comment 9 Jamie Bliss 2004-09-30 23:03:46 UTC
Created attachment 59 [details]
Patch for /includes/ZhConversion.php
Comment 10 Andrew Moore 2004-10-18 01:45:04 UTC
Created attachment 106 [details]
diff to docs/skin.doc to describe how to start creating or modifying a skin

I considered adding this type of information to
http://meta.wikimedia.org/wiki/Skins but that doesn't really look related.
Where should documentation about creating and modifying skins go?
Comment 11 JeLuF 2005-05-01 08:28:20 UTC
Comment on attachment 56 [details]
A patch for version.php relating to documentation (see comment #6)

Version.php does no longer exist, marked as obsolete
Comment 12 JeLuF 2005-05-01 08:30:35 UTC
Comment on attachment 57 [details]
Patch for \maintenance\convertUtf8.php relating to documentation (see comment #6)

Comment is already in the file
Comment 13 JeLuF 2005-05-01 08:31:33 UTC
Comment on attachment 58 [details]
Patch for /includes/SpecialData.php

SpecialData does no longer exist
Comment 14 JeLuF 2005-05-01 08:33:06 UTC
Comment on attachment 59 [details]
Patch for /includes/ZhConversion.php

ZhConversion.php has been documented already.
Comment 15 Ævar Arnfjörð Bjarmason 2005-05-08 18:37:38 UTC
I added an url to the automatically generated todo list at
http://wikipedia.sourceforge.net/doc/todolist.html which mostly contains
documentation todos, let's get to it!
Comment 16 Ævar Arnfjörð Bjarmason 2005-09-03 22:30:16 UTC
Lowering priority
Comment 17 Mark Clements (HappyDog) 2006-04-26 12:29:43 UTC
At www.mediawiki.org we are in the process of creating a comprehensive set of
docs for MediaWiki.  This includes a set of public-domain help files, ultimately
for automatic inclusion in the Help: namespace of new wikis, and a detailed set
of technical documentation released under GFDL.

We would appreciate any help that people can offer, particularly from people who
know the codebase.
Comment 18 Rob Church 2006-11-21 16:02:00 UTC
(re Assignment to Brion)

Is our lead developer now charged with the task of writing documentation AS WELL
as keeping the servers alive, keeping his technical staff in check, keeping his
volunteers from fucking up the codebase and more? That just doesn't seem fair...

The problem of documentation can be split into two; the code documentation
(which isn't too poor, considering) and the public-facing documentation (which
sucks like there's no tomorrow). Code documentation can be handled on an ongoing
basis by the development team. The public-facing documentation would be best off
taken up by a group, such as the one now operating on MediaWiki.org.
Comment 19 Mark Clements (HappyDog) 2006-11-21 16:44:46 UTC
The public-facing documentation is slowly improving at MW.org, as is our more
detailed technical info (e.g. configuration settings, hooks, etc.)

There aren't many active contributors at the moment - the current pattern, in my
experience, seems to be
- a new user appears, sees a hole and does a major bunch of useful updates and
fades into the background
- months pass with users making few tweaks here, a few additional items there
but nothing substansive
- repeat with another user

Eventually we will get a decent set of docs this way, but it will take years...
:(  There are not many contributors who stay and continue to contribute with
regularity.  I am one of the ones who have stayed and even I contribute much
less than would be ideal, and a fair amount of that is vandalism patrol (and
most of the rest is technical documentation or site structuring). Perhaps this
will change when we start moving content over from meta and there are more
people visiting the site as their first port-of-call. Or perhaps a more
concerted effort will be required.

That said, I am optimistic - the site is expanding and improving and becoming
more structured and the user base is definitely growing.

On another note, I am not at all clear what it would take for this bug to be
marked 'FIXED'.  Really, it's an on-going project and there will always be work
to be done, as new versions are released and new features implemented.

I would suggest placing some concrete goals or closing the bug.  Perhaps a good
target would be to make [[mw:Help:Contents]] into a complete list of areas we
want covered, and state that "this bug will be fixed when all direct links from
that page contain a minimum of 3 paragraphs".
Comment 20 Comperr 2006-12-18 16:26:58 UTC
It is an ongoing project as you said....no need to leave it open.
Let us just fix it.
Comment 21 Mark Clements (HappyDog) 2006-12-18 16:41:36 UTC
OK - fixed, verified and reopened in under 3 minutes.  Does anyone want to
comment?  Rob - what's your view?
Comment 22 Rob Church 2006-12-18 16:46:06 UTC
My view is simple. I agree with comment 0. I disagree with closing this bug
until it is solved. Ultimately, it's going to be an ongoing thing, but having
the bug open, at the top of the list, alerts newcomers to the situation and
might encourage them to help us out.
Comment 23 Mark Clements (HappyDog) 2006-12-18 17:33:21 UTC
Does that mean that you think this bug should never be closed, i.e. MW will
always have new or changed features, so the docs are never up to date?

Or, if not, what would it take to close it - are we just talking about end-user
documentation here?  Would it be enough to fill in the holes at
[[mw:Help:Contents]]?  Or do we need to get to the stage where there is a simple
mechanism for importing this documentation into a new wiki?  Or that it is
included in a default MW install? Or have it in X (all?) languages?

Also, does this bug include technical docs as well as end-user docs?
Comment 24 Rob Church 2006-12-22 04:31:15 UTC
*** Bug 3189 has been marked as a duplicate of this bug. ***
Comment 25 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-08-31 03:28:54 UTC
Comment on attachment 106 [details]
diff to docs/skin.doc to describe how to start creating or modifying a skin

Patch is obsolete, there is no includes/SkinPHPTal.php.
Comment 26 digira 2008-02-15 15:54:08 UTC
Neet
Comment 27 charitwo 2008-06-12 07:39:30 UTC
I think Mark Clements is right, as MediaWiki changes, docs will need updating with new and existing feature modifications. There is no need to keep a bug open purely for prospect.
Comment 28 Tim Starling 2008-08-14 09:40:32 UTC
The bug is not meant to be closed. The goal is unattainable, which is why, by simple logical progression, it must stay open. Like the Christian concept of freedom from sin, we can only strive to fix bug 1, we can never actually fix it.
Comment 29 Brion Vibber 2008-10-22 17:14:38 UTC
http://en.wikipedia.org/wiki/Zeno%27s_paradoxes#Achilles_and_the_tortoise

(bumping this bug to test bugmail configuration)
Comment 30 Chad H. 2009-07-29 23:05:16 UTC
*** Bug 20000 has been marked as a duplicate of this bug. ***
Comment 31 Domas Mituzas 2009-08-31 23:54:40 UTC
oh noes
Comment 32 charitwo 2011-02-10 17:28:42 UTC
annoying bug to be CC'd on
Comment 33 Mark Clements (HappyDog) 2011-02-10 23:18:42 UTC
Really, this should be a tracking bug.  Can someone change the summary to "Tracking bug for documentation issues", please?
Comment 34 p858snake 2011-02-10 23:24:35 UTC
(In reply to comment #33)
> Really, this should be a tracking bug.  Can someone change the summary to
> "Tracking bug for documentation issues", please?

It is a tracking bug, it doens't need to the word "tracking" to make it so.
Comment 35 Mark Clements (HappyDog) 2011-02-10 23:46:26 UTC
bug 22710, bug 19719, bug 2114, bug 14720, bug 12788, ... (161 results found)
Comment 36 Tristan Miller 2011-02-11 09:39:01 UTC
> It is a tracking bug, it doens't need to the word "tracking" to make it
> so.

Correct, though it is a rather helpful convention.
Comment 37 p858snake 2011-04-30 00:09:08 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 38 Chad H. 2011-11-29 19:42:45 UTC
*** Bug 7947 has been marked as a duplicate of this bug. ***
Comment 39 Jan Kucera (Kozuch) 2011-12-30 15:50:48 UTC
Because of votes rasing importance/priority according to following scheme:
15+ votes - highest
5-15 votes - high
Community must have a voice within development.

Regards, Kozuch
http://en.wikipedia.org/wiki/User:Kozuch
Comment 40 Helder 2012-05-27 20:06:28 UTC
Tracking bugs usually are blockers for bug 2007.
Comment 41 Mark Clements (HappyDog) 2012-05-28 10:24:31 UTC
It already implicitly blocks bug 2007 by blocking bug 700, so no need to block it directly as well.
Comment 42 555 2012-12-21 23:25:43 UTC
Changed importance to "normal" level. Documentation never should be placed at a low priority unless the developing team or guy wants to be pocked every day with questions "how to do it", "how I can change it" etc.

Changing status to NEW, since the documentation issue will be a new one issue on every possible commit =)
Comment 43 Quim Gil 2013-10-21 17:05:53 UTC
A one-time comment to this tracking report: we are looking for documentation tasks that we could offer to Google Code-in participants. 

Having spoken with the coordinators of the program and participant organizations it is clear that this program is good to complete dozens of little tasks that otherwise are sitting in backlogs forever. Many times bigger goals can be sliced in smaller tasks.

Your help selecting tasks is welcome. See https://www.mediawiki.org/wiki/Google_Code-In#Documentation.2FTraining

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links