Hi Cristóbal & Eric, I would really like to join the website-stuff frontend-todo, but from the wiki it's a bit unclear, which are the public days: 1st/ 2nd/ 3rd or does it already start on the 28? All the best, Gustav On 28/09/15 15:51, Cristobal wrote:

On 27/09/15 09:56, Eric Schaefer wrote:

...

Nice, thanks!

For those of us in Berlin, it would be nice to hash out these last steps to get the blog and website stuff moving forward.

Looks like the website is up for discussion on Wednesday, at least according to the "Public Day Session Ideas" section here: https://trac.torproject.org/projects/tor/wiki/org/meetings/2015SummerDevMeet...

Thanks Eric,

I hope this could serve as discussion material. I've discussed this with @ilv and he would be there at Berlin to bring this up. I've also updated the proposal [1] so now has a working example of how a sample collaborative workflow could be distributed in several repositories:

* tor-website-main [2] for the admin to manage the site structure * tor-website-articles [3] for collaborators to write stuff (this repo contains only *.md files) * tor-website-layouts [4] for designers to work on HTML templates * tor-website-html [5] a static HTML build of tor-website-main

And finally, a live preview at [6].

- Best, Cristóbal

[1] https://trac.torproject.org/projects/tor/wiki/WebsiteProposalClv [2] https://github.com/leivaburto/tor-website-main [3] https://github.com/leivaburto/tor-website-articles [4] https://github.com/leivaburto/tor-website-layouts [5] https://github.com/leivaburto/tor-website-html [6] https://leivaburto.github.io/tor-website-html/

________________________________________________________________________ Tor Website Team coordination mailing-list

To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team

-- Gustav Pursche | Selkestr. 29 | 12051 Berlin Twitter: @gustvv | https://jib-collective.net

Hi! Cristobal:

I hope this could serve as discussion material. I've discussed this with @ilv and he would be there at Berlin to bring this up. I've also updated the proposal [1] so now has a working example of how a sample collaborative workflow could be distributed in several repositories:

* tor-website-main [2] for the admin to manage the site structure * tor-website-articles [3] for collaborators to write stuff (this repo contains only *.md files) * tor-website-layouts [4] for designers to work on HTML templates * tor-website-html [5] a static HTML build of tor-website-main

And finally, a live preview at [6].

Thanks for your input and examples! My current feelings though is that we don't have a clear picture of where we are heading for the website, and how we are going to go there, and who wants to contribute on the content and the layout. So my guts tell me that this is too complicated. Could you elaborate why we could not start with a single Git repository and have dedicated people to review patches and pull requests? -- Lunar <lunar@torproject.org>

Hi Cristóbal, 1) Atom is also available for Mac and Windows - maybe you can drop the note about Linux. But can you add a link to the markdown plugin that you refer to? 2) Content editors are usually keen to put stuff they wrote online immediatly and not have to wait for an admin to hit the publish button. Would that be possible? Like: "give editor A the permission to edit and publish stuff in category B or specifically on page C”? 3) Although I haven’t done any research on that topic lately I suppose there are CMS that allow to publish static sites, provide interfaces for finegrained access control, configurable wysiwyg editors etc. What’s the benefit of using Jekyll and Git? Robustness? Less administration and strain on the server (no DB)? Familiarity of tools? My apologies if this has already been discussed! Ciao Thomas On 28 Sep 2015, at 20:04, Cristobal <clv@riseup.net> wrote:

On 28/09/15 14:01, Lunar wrote:

...

Could you elaborate why we could not start with a single Git repository and have dedicated people to review patches and pull requests?

We could start with a single repository and reviewing patches as well! That would indeed simplify things for the 'dedicated people'. In that case, the difference from what I proposed would be the way of managing commits and pulls, but what I think it's important to point out from my proposal is to have an 'easy way' (in my opinion, of course) to writers to just write, and front-end developers to just design and code in HTML (what I called 'layers': platform, content, presentation).

The git submodules I suggested in the proposal is more of a 'visual' separation to make clear that, for example, tor-website-articles is just about content, and so on.

...

Thanks for your input and examples! My current feelings though is that we don't have a clear picture of where we are heading for the website, and how we are going to go there, and who wants to contribute on the content and the layout. So my guts tell me that this is too complicated.

A good thing to discuss would be... What would encourage (or discourage) people to contribute with content? I saw a comment on #6851 that made me think about that. I quote:

"I am not willing to maintain website translations as long as the website is wml. How about we pick the content that we feel is useful and important and somehow work that into the short user manual (or something similar)?"

One possible answer for that question would be to let people to just write content and not worry about design or platform issues (the same applies for designers and layouts, I think). So, **maybe**, keepings things separated could encourage more people to collaborate with the website.

...

Thanks for your input and examples!

Happy to share my point of view, and willing to collaborate ;)

- Best, Cristóbal

________________________________________________________________________ Tor Website Team coordination mailing-list

To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team

+ thomas lörtsch + hospitalstr. 95 + d 22767 hamburg +49 173 202 71 99 + tl@rat.io + tomlurge@someOtherServices

On 29 Sep 2015, at 14:03, Lunar <lunar@torproject.org> wrote:

thomas lörtsch:

...

2) Content editors are usually keen to put stuff they wrote online immediatly and not have to wait for an admin to hit the publish button. Would that be possible? Like: "give editor A the permission to edit and publish stuff in category B or specifically on page C”?

Who are we talking about? I'm not sure this has been clearly identified yet.

E.g. me working on visionion. I don’t need or want to or maybe even should not be able to edit any other pages on the site than the one describing my project. But I’d like to see my edits on “my” page immediatly published and live on the internets instead of having to wait for or having to bug an admin - not the least because instant gratification makes for better motivation. And I would feel more “in control".

...

3) Although I haven’t done any research on that topic lately I suppose there are CMS that allow to publish static sites, provide interfaces for finegrained access control, configurable wysiwyg editors etc. What’s the benefit of using Jekyll and Git? Robustness? Less administration and strain on the server (no DB)? Familiarity of tools? My apologies if this has already been discussed!

The Tor website needs to be easily reproduced on as many different mirrors as possible. Using a website generator that creates static content is the easiest way to create a website that can be easily synchronized on multiple servers.

For the Tor website, I don't really see what could require content that needs to be generated on the fly.

The need to publish static sites is out of question and I don’t see the need for on-the-fly-generation neither. My question is if a proper CMS wouldn’t be beneficial for administering user rights management and could provide niceties like a wysiwyg editor. I reckon there are CMS that can produce a static site with the push of a button just like Jekyll can. Again my apologies if this has been discussed before or if the can of worm it opens is just to unbearable. Ciao Thomas

I'm Liam, What exactly is this proposal? You guys have been going back an forth. What's the proposal? On 9/29/2015 8:54 PM, Cristobal wrote:

Hi Thomas,

On 28/09/15 19:12, thomas lörtsch wrote:

...

1) Atom is also available for Mac and Windows - maybe you can drop the note about Linux. But can you add a link to the markdown plugin that you refer to? Thanks! I've added the link to the "Markdown preview" plugin [1].

...

2) Content editors are usually keen to put stuff they wrote online immediatly and not have to wait for an admin to hit the publish button. Would that be possible? Like: "give editor A the permission to edit and publish stuff in category B or specifically on page C”? Good question! Indeed, if you use separated repositories, then you could "create" your own set of rules for authorizing contributors. For example, the articles repo could have a set of authorized core-editors to push directly, without needing review, and at the same time accept patches (with review) from non-core-editors. You could go even further with the possibility of having different teams of "editors" for different type of posts. I've updated the example repository [2] and you can see that inside the folder '_posts' there are two git submodules (abbreviated to A and B) and, as they are different repositories, they can have different users authorized for each one of them. The good thing is that Jekyll ignores the subfolders in '_posts' and publishes all the articles, so you could create as many folders as roles you need! If you visit the main website [3] you will see that there are 3 published articles... 2 came from tor-website-articles and the other from tor-website-articlesb.

I haven't tried yet, but I'm pretty sure you could play with git hooks [4][5] to "automatize" the process of pulling the changes in the main repository after a push was done on the articles repository.

...

3) Although I haven’t done any research on that topic lately I suppose there are CMS that allow to publish static sites, provide interfaces for finegrained access control, configurable wysiwyg editors etc. What’s the benefit of using Jekyll and Git? Robustness? Less administration and strain on the server (no DB)? Familiarity of tools? My apologies if this has already been discussed! AFAIK jekyll and pelican are the most popular solutions out there (last time I checked... though I might need to update my research on that).

A CMS is kind of the opposite of static websites. With a CMS you can handle authorization, roles, UI, etc. but with a cost of resources (DB, dynamic languages) and security. A static website generator removes all of that features (to reduce resource requirements and improve security) and let the "owner" take care of that issues as he pleases. That could be the reason why static website generators are more focused on personal websites rather than communities.

In this case, a combination of a static website generator with tools such as git would enable us to emulate, partially, a CMS (git -> versioning and distributed content, git submodules -> authorization and roles, atom -> UI, etc). The production server (torproject.org) would need nothing more than a web server to render HTML files (Nginx or Apache). That means: more security (less attack vectors), better performance (less strain on the server), less maintenance issues, easier to perform load balancing, etc.

...

Ciao Thomas

Thanks for your questions! Don't hesitate to reply back if something is unclear.

- Best, Cristóbal

[1] https://atom.io/packages/markdown-preview [2] https://github.com/leivaburto/tor-website-main/tree/gh-pages/_posts [3] https://leivaburto.github.io/tor-website-main [4] http://githooks.com/ [5] https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

________________________________________________________________________ Tor Website Team coordination mailing-list

To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team