Opening bug to track migrating hacking documentation from www.mozilla.org. Much of the hacking content seems to already be on MDC according to the Needs Redirect page, so I can go through and redirect and remove any of that duplicated content. For the rest of the documentation we should decide if it should be migrated to MDC or archived. The policy documents currently in hacking should stay on www.mozilla.org either where they are now or in the policies folder. cc'ing gerv, dbaron, eshepherd. The ownership of hacking is unclear to me, so please suggest other people who should be involved in this discussion.
I've set up redirects for the following pages based on information from MDC's Needs Redirect page and will remove these from CVS: /hacking/mozilla-style-guide.html /hacking/code-review-faq.html /hacking/development-strategies.html /hacking/new-features.html /hacking/life-cycle.html /hacking/coding-introduction.html There were a couple of things on MDC's Needs Redirect page that I had comments about. http://www.mozilla.org/hacking/module-ownership.html I think this is a policy document that should stay on www.mozilla.org. There is currently a page for this on MDC that would need to be redirected. I'll remove this from the Needs Redirect page. http://www.mozilla.org/hacking/getting-cvs-write-access.html There is already a redirect set up that points MDC's version of this page to the version on www.mozilla.org. I'll remove this from the Needs Redirect page.
There are several Best Practice files in Hacking that are just placeholders. http://www.mozilla.org/hacking/best-coding-practices.html http://www.mozilla.org/hacking/best-cpp-practices.html http://www.mozilla.org/hacking/best-css-practices.html http://www.mozilla.org/hacking/best-js-practices.html http://www.mozilla.org/hacking/best-xpcom-practices.html http://www.mozilla.org/hacking/best-xul-practices.html The only ones with any content are the Coding and C++ Practices pages, but even these are just rough notes. I'm going to remove the 4 empty placeholder files. Sheppy, is any of the content for the Coding and C++ Practices pages worth keeping or does this exist somewhere else that I could redirect to?
Kairo, what would you like to do with the SeaMonkey-related content in Hacking? For example: http://www.mozilla.org/hacking/working-with-seamonkey.html http://www.mozilla.org/hacking/tree-mgmt.html The Hacking index page is also pointing to a couple of SeaMonkey pages that are bringing up 404 errors. We could either remove those links or set up redirects. http://www.seamonkey-project.org/rules/bible.html http://www.seamonkey-project.org/rules/code_review.html
(In reply to comment #3) > Kairo, what would you like to do with the SeaMonkey-related content in Hacking? > For example: > > http://www.mozilla.org/hacking/working-with-seamonkey.html This was really changed in 2002 the last time, and refers to "SeaMonkey" as the app suite which was the main tree at that time to differentiate to the m/b stuff that was created back then with lazy tree rules and almost no review and not following the usual rules. To make it short, what is called "SeaMonkey" there should probably be "the main Mozilla app tree as of 2002" ;-) > http://www.mozilla.org/hacking/tree-mgmt.html Same with this (is that doc different from the former?) > The Hacking index page is also pointing to a couple of SeaMonkey pages that are > bringing up 404 errors. We could either remove those links or set up > redirects. > > http://www.seamonkey-project.org/rules/bible.html > http://www.seamonkey-project.org/rules/code_review.html bible.html or code_review.html have nothing to do with the current SeaMonkey project and also date back to the early days of Mozilla where "SeaMonkey" was the name of the project for releasing binary packages of the main Mozilla product that was the Netscape-style suite back then. Please don't redirct them to seamonkey-project where they don't belong.
Kairo, thanks for your feedback. If those "SeaMonkey" pages in Hacking predate the current use of SeaMonkey then I think it's probably safe to archive them. I'll remove those pages and will also remove those links from the index page.
Sheppy, what would you recommend that we do with the following? http://www.mozilla.org/hacking/rules.html http://www.mozilla.org/hacking/ui-difficulties.html http://www.mozilla.org/hacking/cpp_portability/index.html
I could go either way between moving that stuff to MDC or keeping it on mozilla.org, although I think I lean slightly toward moving it to MDC because it's a policy about coding style. However, I can totally go either way. We can cross-link as needed, so it's not likely a big deal either way.
As far as the C++ Portability stuff goes, there's already a page on MDC at http://developer.mozilla.org/En/C___Portability_Guide The C++ Portability docs referenced in comment #6 are slides from a talk Scott Collins gave a long time ago. http://www.mozilla.org/hacking/cpp_portability/index.html AFAICT, the files mentioned in comment #2 and comment #6 are obsolete, but it would be good to have someone verify that before I archived them.
I think the slides are actually useful, since they give a lot more motivation than the guidelines do.
David (Baron), should we move the useful parts of the slides into the guide on Devmo? Otherwise, I think a link to the archived version of them on the Devmo article would be fine. David (Boswell), everything else you mentioned in comment 2 and 6 looks like it's obsolete. rules.html can be redirected to either https://wiki.mozilla.org/TreeStatus or http://developer.mozilla.org/en/mozilla-central ... Note that the former includes rules for the Firefox3.0 tinderbox, but those rules also exist on the tinderbox page itself. How do people feel about moving regression-policy.html and reviewers.html to /developer/?
(In reply to comment #10) > How do people feel about moving regression-policy.html and reviewers.html to > /developer/? I don't think we should get rid of /hacking/, so if there's stuff that's clearly hacking-related that's tied to policy or such, I'm perfectly happy to keep it in /hacking/.
I just archived: http://www.mozilla.org/hacking/best-coding-practices.html http://www.mozilla.org/hacking/best-cpp-practices.html http://www.mozilla.org/hacking/ui-difficulties.html I also redirected and removed: http://www.mozilla.org/hacking/rules.html I think there are just two open issues left for the hacking pages: - What to do with http://www.mozilla.org/hacking/cpp_portability/index.html - What to do with the hacking homepage? I agree we want to keep the directory, but if hacking is now just a repository for policies then the current hacking home page may make more sense as an introductory guide to new developers that's hosted on MDC. The hacking main page could then be redirected to the new policies page or to that new introductory page.
(In reply to comment #12) > - What to do with the hacking homepage? I agree we want to keep the directory, > but if hacking is now just a repository for policies then the current hacking > home page may make more sense as an introductory guide to new developers that's > hosted on MDC. Why do you agree we want to keep it? Emotional sentiment? We could find emotional reasons to keep every section of the site. But, if everything in /hacking/ is policies, we should move the pages to the policies directory and archive the pages. I'm of the mind that it should be redirected to something on MDC. Maybe we update whatever page that we send people to so that it includes some of the same content as the hacking page now (the relevant parts, of course).
Re comment #13 about keeping the hacking directory: At our recent planning meeting we decided to keep policy pages where they are unless they were in a random place that didn't make any sense. We can revisit this on another call if you'd like. Re comment #13 about the home page: Let's see what Eric says about migrating this to MDC.
I think putting the hacking home page on MDC is a good idea; we can then link back over to mozilla.org where appropriate for policies.
Re comment #15, in the interest of having the main Hacking page point somewhere useful, would anyone object to redirecting that page to the Hacking Mozilla page on MDC and redirecting it later to another MDC page as needed? http://developer.mozilla.org/en/Hacking_Mozilla
(In reply to comment #16) > Re comment #15, in the interest of having the main Hacking page point somewhere > useful, would anyone object to redirecting that page to the Hacking Mozilla > page on MDC and redirecting it later to another MDC page as needed? > > http://developer.mozilla.org/en/Hacking_Mozilla No objection from me, but the content on that page is outdated. Somebody should work on it sometime, I guess.
http://www.mozilla.org/hacking/ is one of the most useful summaries of information about hacking Mozilla (and the one I generally point people to). I would object to redirecting it to something significantly less useful.
dbaron what parts of that page do you want people to see? i regularly wonder if any of it is still useful, so it would be great to know what parts you think are still relevant.
We have an ongoing problem wherein we want to migrate and reorganize content, but we get feedback along the lines of, "That page still has useful stuff, don't mess that up," but then never get anyone to figure out what needs to be kept and what we should toss.
What's useful about it is that it has a collection of links relevant to people who are new to writing code for Mozilla: * links to the important standards code has to meet: C++ portability, performance * life cycle of a patch, how code review works, and who to contact about moving patches forward * how we give CVS access to the repository that describe to somebody who wants to develop Mozilla code what rules they'll be dealing with and what standards they'll be expected to meet. Some of the documents it points to are a bit out-of-date (e.g., precheckin tests, hook) and there are a few pointers we should probably add (e.g., unit tests, topcrashes), but I don't know of anything else that gathers up pointers to that information as well.
(In reply to comment #20) > We have an ongoing problem wherein we want to migrate and reorganize content, > but we get feedback along the lines of, "That page still has useful stuff, > don't mess that up," but then never get anyone to figure out what needs to be > kept and what we should toss. I'd describe the ongoing problem a little differently: we have a group of people who want to migrate, reorganize, and delete content, but don't see it as part of their responsibility to learn who uses on that content, or why, or who currently maintains it. Rather, they expect those who depend on the content to stop whatever they're doing and immediately explain why it's important in order to stop changes from being made (which tends to lead to short explanations).
So i'd be inclined to (1) delete everything that dbaron hasn't identified as important, and (2) somehow change the navigation so that this isn't one of only 5 or 6 items we present at the top level.
The trick for us is that we try to collect this information by asking folks what needs to be kept, and don't get useful answers a lot of the time. For example, I'll ask, "What on this page is obsolete?" and as a response, I get "That page still has useful information, even though some of it is obsolete." That's not helpful. :) How are we supposed to learn what's still useful, what isn't, and who's responsible for the content without asking? We have to get clean up our content. Keeping obsolete material around forever, and correct information in the wrong places, is not helpful to the community as a whole, but only to the people who happen to already know their way around.
I agree with dbaron's comments in #21 -- the developer information on the Hacking page is worthwhile. Since it's developer documentation the plan is to move it to MDC where it belongs. Would it solve the problem to just copy the Hacking page as is and move that to MDC? If so, please suggest a name since Hacking Mozilla and Mozilla Hacker's Getting Started Guide are taken. The problem with the Hacking content as I see it is that it was a mix of developer docs, policy docs and information about the project. The policy and project content has been moved to the About section on www.mozilla.org and now we need to wrap things up by moving the rest of the developer content.
(In reply to comment #24) > For example, I'll ask, "What on this page is obsolete?" and as a response, I > get "That page still has useful information, even though some of it is > obsolete." The sense I get is that you're asking "What on this page isn't obsolete?". I'd be much happier if you were asking "What on this page is obsolete?" (as you wrote just now). The distinction I'm trying to make is like the distinction between "guilty until proven innocent" and "innocent until proven guilty". My complaint is that stuff is being deleted with the rationale "nobody told me it's not obsolete" rather than the rationale "I think this is obsolete because ...", and that's what leads me to reflexively yell "No" every time I hear of something proposed for deletion that I think i useful or partly useful. In the last paragraph of comment 21 I did point out a few pieces that I think are obsolete.
bsmedberg has been working on recreating what /hacking/ should be (in his view, I guess) as the Mozilla Developer's Guide: https://developer.mozilla.org/En/Developer_Guide I think that's a positive step, and I recently went through and made sure that everything important linked from /hacking/ was also linked to from there. So, I think we are now in a position to redirect /hacking/index.html (only; I know other documents still continue to live in that directory) to the Developer's Guide URL given above. (This obviously doesn't resolve this bug entirely.) This has been discussed in the governance newsgroup (admittedly not necessarily the most appropriate one, but it was an offshoot of another discussion) and seems to have met with no objections, but I was asked to summarise the discussion here too. Gerv
Gerv sounds good. Great, actually to get more of the obsolete content out of the main content areas.
OK, I have now checked in the change which does that. Checking in .htaccess; /www/mozilla-org/html/.htaccess,v <-- .htaccess new revision: 1.204; previous revision: 1.203 done Gerv
I just archived Scott Collin's C++ Portability presentation in r90313. This means the content is still available at the same URL (people will automatically get redirected to the same content on the archive site) but the files aren't on the production server anymore. http://www-archive.mozilla.org/hacking/cpp_portability/index.html
Gerv, can you take a look through the pages remaining in /hacking and see if there's anything left to archive or if it's all relevant content now? I scanned through the repository and nothing obviously abandoned stood out to me. If anyone else wants to look through the files, you can browse the repository at http://viewvc.svn.mozilla.org/vc/projects/mozilla.org/trunk/hacking/
Assignee: nobody → gerv
If removing files automatically redirects you to an archive copy, then the following can be removed as they are obsolete: incubator-repository.html getting-svn-write-access.html I don't know if regression-policy.html is still a live document. The rest is still current. Gerv
> getting-svn-write-access.html I just archived this page in r91107. > incubator-repository.html I didn't archive this page yet since it doesn't exist on the archive site right now (the archive is a snapshot of www.mozilla.org from April 21, 2008 and this page was added after that date). There are a couple of options: move the page over to the archive site (and risk messing with the time-space continuum by having the page be older than the note on the page) or just leave the page where it is for now. > I don't know if regression-policy.html is still a live document. If anyone has information on this page, please let us know. So if we want to leave the incubator-repository.html page where it is and the regression-policy.html page is active, we can close this bug out.
I'll go ahead and close this bug. We can revisit archiving anything else if we get more information about something being inactive.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.