This repository has been archived by the owner. It is now read-only.
Permalink
Browse files

First pass at Playdoh -> Fjord

  • Loading branch information...
willkg committed Jul 27, 2012
1 parent 4f863cc commit eebed8d7c396518bb9d11e204562728b60e1ef32
Showing with 528 additions and 103 deletions.
  1. +1 −1 LICENSE
  2. +0 −23 README.md
  3. +5 −0 README.rst
  4. +0 −40 docs/build-github.zsh
  5. +8 −8 docs/conf.py
  6. +8 −0 docs/contactus.rst
  7. +36 −0 docs/contributors.rst
  8. +69 −0 docs/conventions.rst
  9. +382 −0 docs/hacking_howto.rst
  10. +10 −18 docs/index.rst
  11. +9 −13 fjord/settings/local.py-dist
View
@@ -1,4 +1,4 @@
-Copyright (c) 2011, Mozilla
+Copyright (c) 2012, Mozilla Foundation
All rights reserved.
Redistribution and use in source and binary forms, with or without
View
@@ -1,23 +0,0 @@
-playdoh
-=======
-
-Mozilla's Playdoh is a web application template based on [Django][django].
-
-Patches are welcome! Feel free to fork and contribute to this project on
-[github][gh-playdoh].
-
-Full [documentation][docs] is available as well.
-
-
-[django]: http://www.djangoproject.com/
-[gh-playdoh]: https://github.com/mozilla/playdoh
-[docs]: http://playdoh.rtfd.org/
-
-
-License
--------
-This software is licensed under the [New BSD License][BSD]. For more
-information, read the file ``LICENSE``.
-
-[BSD]: http://creativecommons.org/licenses/BSD/
-
View
@@ -0,0 +1,5 @@
+=======
+ Fjord
+=======
+
+FIXME
View
@@ -1,40 +0,0 @@
-#!/bin/zsh
-
-# A useful build script for projects hosted on github:
-# It can build your Sphinx docs and push them straight to your gh-pages branch.
-
-# Should be run from the docs directory: (cd docs && ./build-github.zsh)
-
-REPO=$(git config remote.origin.url)
-HERE=$(dirname $0)
-GH=$HERE/_gh-pages
-
-
-# Checkout the gh-pages branch, if necessary.
-if [[ ! -d $GH ]]; then
- git clone $REPO $GH
- pushd $GH
- git checkout -b gh-pages origin/gh-pages
- popd
-fi
-
-# Update and clean out the _gh-pages target dir.
-pushd $GH
-git pull && rm -rf *
-popd
-
-# Make a clean build.
-pushd $HERE
-make clean dirhtml
-
-# Move the fresh build over.
-cp -r _build/dirhtml/* $GH
-pushd $GH
-
-# Commit.
-git add .
-git commit -am "gh-pages build on $(date)"
-git push origin gh-pages
-
-popd
-popd
View
@@ -1,6 +1,6 @@
# -*- coding: utf-8 -*-
#
-# playdoh documentation build configuration file, created by
+# fjord documentation build configuration file, created by
# sphinx-quickstart on Tue Jan 4 15:11:09 2011.
#
# This file is execfile()d with the current directory set to its containing dir.
@@ -40,17 +40,17 @@
master_doc = 'index'
# General information about the project.
-project = u'a playdoh-based project'
-copyright = u'2011, the authors'
+project = u'a fjord-based project'
+copyright = u'2012, Mozilla Foundation'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
-version = '1.0'
+version = 'dev'
# The full version, including alpha/beta/rc tags.
-release = '1.0'
+release = 'dev'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
@@ -164,7 +164,7 @@
#html_file_suffix = None
# Output file base name for HTML help builder.
-htmlhelp_basename = 'playdohdoc'
+htmlhelp_basename = 'fjorddoc'
# -- Options for LaTeX output --------------------------------------------------
@@ -178,7 +178,7 @@
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass [howto/manual]).
latex_documents = [
- ('index', 'playdoh.tex', u'playdoh Documentation',
+ ('index', 'fjord.tex', u'fjord Documentation',
u'Mozilla', 'manual'),
]
@@ -211,7 +211,7 @@
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
- ('index', 'a-playdoh-app', u"a-playdoh-app's Documentation",
+ ('index', 'a-fjord-app', u"a-fjord-app's Documentation",
[u'the authors'], 1)
]
View
@@ -0,0 +1,8 @@
+.. _contact-us-chapter:
+
+==========
+Contact us
+==========
+
+:irc: #input on irc.mozilla.org
+:new bugs: https://bugzilla.mozilla.org/enter_bug.cgi?product=Input&rep_platform=all&op_sys=all
View
@@ -0,0 +1,36 @@
+.. _contributors-chapter:
+
+==================
+Join this project!
+==================
+
+Fjord is the software that will run `Input (input.mozilla.org)
+<http://input.mozilla.org/>`_ which allows Mozilla project to gather
+feedback from its user base.
+
+Interested in helping out? Here's a bunch of things we need your help
+with.
+
+
+Help with hacking!
+==================
+
+First step is to set up Fjord so you can run it and hack on it. For
+that, see the :ref:`hacking-howto-chapter`.
+
+If you have problems, please let us know! See
+:ref:`contact-us-chapter`.
+
+After you've got it up and running, come say hi!
+
+
+Help with making Fjord easier for hacking on!
+=============================================
+
+We're working on making Fjord easier to hack on. This entails:
+
+* making this documentation better
+
+Any thoughts you have on making this easier are much
+appreciated. Further, if you could help us, that'd be valuable to us
+and all those who follow in your footsteps.
View
@@ -0,0 +1,69 @@
+===========
+Conventions
+===========
+
+This document contains coding conventions, and things to watch out
+for, etc.
+
+
+Coding conventions
+==================
+
+We follow most of the practices as detailed in the `Mozilla webdev
+bootcamp guide
+<http://mozweb.readthedocs.org/en/latest/coding.html>`_.
+
+If you don't have an editor that checks PEP-8 issues and runs pyflakes
+for you, it's worth setting it up. Use `check.py
+<https://github.com/jbalogh/check>`_ because it's awesome.
+
+
+Git conventions
+===============
+
+Git workflow
+------------
+
+We use a rebase-based workflow.
+
+
+Git commit messages
+-------------------
+
+Git commit messages should have the following form::
+
+ [bug xxxxxxx] Short summary
+
+ Longer explanation with paragraphs and lists and all that where
+ each line is under 72 characters.
+
+ * bullet 1
+ * bullet 2
+
+ Etc. etc.
+
+
+Summary line should be capitalized, short and shouldn't exceed 50
+characters. Why? Because this is a convention many git tools take
+advantage of.
+
+If the commit relates to a bug, the bug should show up in the summary
+line in brackets.
+
+There should be a blank line between the summary and the rest of the
+commit message. Lines shouldn't exceed 72 characters.
+
+See `these guidelines
+<http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html>`_
+for some more explanation.
+
+
+Git resources and tools
+-----------------------
+
+See `Webdev bootcamp guide
+<http://mozweb.readthedocs.org/en/latest/git.html#git-and-github>`_
+for:
+
+* helpful resources for learning git
+* helpful tools
Oops, something went wrong.

0 comments on commit eebed8d

Please sign in to comment.