Tails

#4 Updated by tchou 2015-06-10 21:04:18

Some extra improvements on this repo :

- generalize and unify panel markup
- back button style

#6 Updated by tchou 2015-06-12 12:46:42

New repo, please forget the old one : https://git-tails.immerda.ch/tchou/tails/log/?h=web/assistant

#10 Updated by sajolida 2015-06-28 14:57:04

First of all, it’s really cool to be able to see all our work on web
pages, yeepee! I also find that Bootstrap looks both great and easy to
read. Now that your code changes most of those pages, I will refrain
from modifying the content, for example from tasks Feature #9559 and Feature #9441
until I can merge your changes or otherwise we will have to deal with
many deep conflicts.

Here are some comments, some of them are more serious than others. I’m
also conscious that I am a bit maniac and we should work on finding a
level of expectations that is both acceptable for the project and
comfortable for you. Don’t hesitate to tell me when you think I’m
exagerating.

I think we have two options to continue working on this:

1. You do incremental improvements on your code to fix those issues as
commits add to your branch.
2. You rewrite your commits and change the history of your branch.

Ideally I would like to improve on the Git history (read on about
that) and on the total diff (git diff origin/web/assistant...web/assistant).

About code style:

I think that having consistent and beautiful code is useful to make it
easier to read, easier to modify and maintain, and easier for
translators to translate. To the light of this, here are a few
comments:

• Avoid trailing white spaces. You can spot them in your commits by
  activating colors, see 9130#note-12. Then you can do git diff origin/web/assistant...
• Please do smaller commits. A commit should correspond to one idea or
  one problem. It should be possible to revert or analyse commits
  separately. Big commits make it harder to understand you work as
  several things get mixed up. At least separate changes on the
  content from changes in the format. For example, your commits
  commit:3423fc9 and commit:37bd3d8 are good. But your commit
  commit:4f99f0f mixes way to many changes. It might be hard (but not
  impossible) to rewrite the history of your commits to make them
  smaller. You can start by doing git reset d301037.
• Also try to limit your impact on the existing code to have smaller
  diffs. I’m not sure that’s possible in your case but that’s an idea
  to keep in mind: if you can leave a line unchanged, try to do it.
• Please use indentation consistenly. So far we’ve been using ’ ’ to
  indent HTML. You’re mixing ’ ’ with tab. I prefer ’ ’ and sometimes
  don’t indent in order HTML indentation, you’re mixing both ‘tab’ and
  ’ ’ inconsistently, let’s do the same thing everywhere.
• Avoid empty lines. For example in
  wiki/src/install/debian.mdwn. Making your code more compact (but not
  too much) makes it faster and easier to read.
• Add empty lines between separate blocks of text (or code). Otherwise
  translators will see them as a single string. For example on
  install.mdwn there should be an empty line between <h1>Welcome to the Tails Installation Assistant</h1> and Thank you for your interest in Tails..
• Use full HTML and always add <p> for example inside a <div>. For
  example in <div class="panel-body">If you know someone of trust who uses Tail. Otherwise this might break your formatting or produce
  unexpected results as the HTML wouldn’t validate.
• Avoid unecessary spaces. For example in <li> 25 minutes to install. I’m not a browser compatibility expert but I could see
  this creating problems in some unexpected corner cases.
• Why not use consistent color codes? So far we’ve been using the
  format #rrggbb consistently. You started using rgb(40,40,40) and
  green. I could see this creating problems if we want to use grep
  or replace one color by another everywhere consistently in the
  future.

About the code itself:

• Use title="" in the metatag works as well and is shorter (until
  http://ikiwiki.info/bugs/meta_plugin_should_not_add_alternate_stylesheets_and_title_by_default/
  gets solved).
• You have a typo on <li> 25 minutes to install</li.

About the formatting:

• We haven’t used SVG images so far. I think that boum.org doesn’t
  have whatever imagemagick dependency required to use them. We could
  probably ask them to add this. I’m also wondering whether this can
  cause display issues on older browsers or security issues (it is
  possible to add executable code to SVG images). Do you think we
  could use PNG instead? If so please also use the script I added with
  commit:4a1bf7d to compress them.
• Why did you choose to switch to a blue theme (or maybe that’s
  temporary only). What about reusing our usual color sheme with
  purple and green?
• I find the grey on the minor (DVD + VM) way to pale and can hardly
  read it. I’d rather format them more explicitely as links using our
  usual colors.

That’s quite a lot of comments already, so I’ll stop here. Good luck
with Git and don’t hesitate to ask for help on using it.

#17 Updated by intrigeri 2015-11-01 01:17:27

> I think my text editor is suppose to kick it now before saving, but I should check again. I don’t always go git diff before commiting.

Hint: git diff --cached (after git add -p and/or git add $FILE) shows you what you are going to put in the commit you’re preparing, that is what will be recorded next time you run git commit.

> I tried to use single spaces, but it’s very difficult for me to read the code after so I did it with tabs.

Could N-spaces (N = 2 like in Ruby, or a larger N like in most other programming languages) be a compromise that works for everyone?

(All Tails stuff is standardized on “no tabs”, and FYI introducing tabs in this context makes collaborative work painful. It’s not just a matter of “everything must be the same because of my OCD”, I can elaborate privately if you wish :)

#18 Updated by tchou 2015-11-01 02:35:41

intrigeri wrote:
> > I think my text editor is suppose to kick it now before saving, but I should check again. I don’t always go git diff before commiting.
>
> Hint: git diff --cached (after git add -p and/or git add $FILE) shows you what you are going to put in the commit you’re preparing, that is what will be recorded next time you run git commit.

I know this one (as “--staged” too).

> > I tried to use single spaces, but it’s very difficult for me to read the code after so I did it with tabs.
>
> Could N-spaces (N = 2 like in Ruby, or a larger N like in most other programming languages) be a compromise that works for everyone?

Actually, I think it’s what I do, but I can ask my editor to normalise the codebase.