Here's an expanded, modified version of the original structure I was suggesting.
Paths (/Foo/Bar) are suggested page names / structures. Links are existing pages that seem related and can be used as a base for the new article, or as a base for a subpage of that article.
How do you all feel about subpages? Do you find it helpful in organizing, or will it just make the page names harder to remember?
Note: Categories are helpful for finding everything related, but bare category pages ted to be overwhelming because they're strictly alphabetical order, not priority order, and a category can get pretty broad (e.g., all howtos, even those for a completely unrelated topic), so we need something besides.
I haven't listed all the pages. There are a few groups of pages documenting all the database tables, or a bunch of howtos on closely related topics; I've marked those as "(prefix)".
Despite the number of links, again this is not all that I expect the wiki should contain. But by now I hope that this is enough to make it obvious where additional pages could go.
We've been gradually building up articles on the wiki, which is good because wiki == good, but it can be a bit overwhelming for someone new because they won't know where to start.
I propose reorganizing the articles under the Development section: I don't want to constrain things too much, but I think slotting things in more clearly will be helpful for both new and old alike.
We're partway there because of the fine work people have put into Dev Getting Started, but I want to sit down and rethink the split a bit.
What I have in mind is to split up the pages into one-time steps and steps that have to be repeated over and over again, and revise how things are arranged and highlighted in Dev Getting Started. So instead of having a Bugzilla page and a Github page and etc, we have something like the following:
- one-time setup
- dev environment (scratch installation / getting a hack)
- bugzilla (registering, username conventions)
- github (forking etc)
- working on stuff (the basics)
- programming guidelines
- finding things
- claiming a bug -> submitting a pull request, including conventions etc
- editing in case of a review
- updating code (dev maintenance)
- one-time setup
This is more specific resources. Everything under here to be a subpage of /Development?
- everything in the getting started section
- submitting hotfixes on a release branch /Development/Release
- setting up various modules /Development/Setup? Tools? Server?
- schwartz /Development/Setup/Schwartz
- search / sphinx
- howto /Development/Howto
- new userprop
- database table (create, edit)
- edit a database table
- beta feature
- enable shop items
- enable paid time
- stuff under /admin (/admin/pay, etc)
- explain stuff under /dev (/dev/classes, /dev/eventoutput, etc)
The examples provided aren't definitive, just examples of what we have and need off the top of my head. There are plenty of articles on the wiki that aren't yet in this list but could fit (most probably under /Development).
Would this structure be helpful for you? What would be most useful to highlight in Dev Getting Started? I'd like to request that we focus on overall structure before specific page suggestions as much as we can, so that it's easier for people to find what they need in the pages we already have.
I'm updating documentation to remove mentions of Mercurial and replace with resources for Git. I'm also trying to go through the flow of pages, starting from the main page, hopefully figuring out what someone new to the project will click on...
Right now I'm doing a depth-first traversal of links, starting from the "Dreamwidth Developers" section of the main page.
Dev Getting Started - changed paragraphs to a list for easier scannability. Moved stuff from the intro at the top to a "what you need" section / removed the two paragraphs on installing a dev environment since they somewhat are repeated below or in other pages.
Bugzilla - made the link to workflow more visible, removed needs-review / needs-commit from saved searches
Dreamwidth Scratch Installation - adjusted references from etc/config* to ext/local/etc/config*; removed paragraphs from the "Starting development section", instead linking back to "Dev Getting Started" to centralize
Main development folder - moved to Directory Structure
Dev Patches - obsolete, deleted. Will replace anywhere that refers to this to the git workflow
Draft: Github development process - forward to Version Control
Version Control - replace with old contents of Github development process
Stopping for now; have worked my way through the links at http://wiki.dwscoalition.org/wiki/index.
I'll post further changes in another entry.
ETA: The update is complete--keep me posted on any issues you have!
- resource concatenation
- clustered setup
- cron jobs for maint scripts + recommended schedule ( which need daily, which weekly, which whenever, etc.. )
- running purges
- ... I am probably missing more things...
What we need to do is go through our documentation and change:
* Links to the old hg.dwscoalition.org repository to their new equivalents on https://github.com/dreamwidth/dw-free
* Descriptors that refer to cvsreport.pl, which no longer exists, especially in update contexts
* Installation instructions
* Documentation on code layout--cvs directory no longer exists, for example
And anything else that we can think of. The Development category is in need of special attention.
We also need to start creating best practice policies (for instance, do development on branches your create) and putting them onto the wiki. We do have one new page with a first draft of instructions so far on:
Moving your Dreamwidth installation to use Github
Feel free to comment on this post with anything you see that needs updating, if you don't feel like updating it yourself!
Update: The server OS and the wiki software have both been updated to recent versions. There may be some problems to work out still, as Special:SpecialPages is erroring out.
Update 2: Tracked down the erroring out to the OpenID extension, which is now properly updated.
This strategy no longer works and I need to figure out a new one. The OpenID plugin has a setting to only allow OpenID logins, but that then blocks out non-OpenID users. In the meantime, registration is turned off because I can't keep dealing with the many, many spam registering accounts that have been constantly happening since I turned regular registration on. There might need to be Captchas, or some other strategy.
- SemanticQueryFormTool can't be used anymore with the most recent version of Semantic Mediawiki
- Right now it's on the default MW skin and I took one of the icons to use for the logo. I'm very very open to new logos--the size to shoot for is 135px by 135px. I might tweak the CSS for the skin a little, but mostly I'll keep to the standard.
If you can go test out the wiki and make sure you can log in, that would be dandy!
To filing a new bug in this category, select "Project Documentation" as the product and "Wiki documentation" as the component.
(*) So far, TheSchwartz is done, Gearman is next (haven't started), and when I'm done I may do Memcache and MogileFS.
The latter is lots more comprehensive, but the former has some interesting semantics code in the source, which I'm not sure how to port over.
Hello, folks! I have upgraded the wiki to version 1.16 of Mediawiki. Let me know if you run into any weirdness.
I also feel like I should note that I have modified an extension for the browser editor jEdit to let people edit the Dreamwidth wiki using it. Is anybody interested in me distributing this? Let me know!
There's three things that will greatly help us with this rather large task.
* Update articles to make them useful. There's all sorts of ways to browse them - use the Wiki Toolbox to find some if you need.
* If you don't have the information to update it, but know it needs updating, add this textbox to the top of the page: http://wiki.dwscoalition.org/notes/
* If you think a page should just be deleted entirely, add this box to the top of the page: http://wiki.dwscoalition.org/notes/
Myself or foxfirefey can elevate privs on the Wiki if there is some function that would be useful to you that you don't have.
Thanks for all that you do.
It'd be good for folks to keep an eye on the Recent Changes page for other vandalbot activity. If you know how to rollback changes, feel free to, but comment here if you don't. It might also be good to comment here if you do, to keep track of this issue. If they start hitting a wide variety of pages, we might have to look into deterrence methods (like setting it up so that ReCaptcha triggers on all edits by nonregistered users).
For instance, http://wiki.dwscoalition.org/notes/