the project's website

[myrdd]

Summary:

• the old website is https://www.requestpolicy.com/ (though theSSL/TLS certificate expired)
• currently we offer a beta xpi extention file on https://sslsites.de/requestpolicy.256k.de/ (it hosts also update-beta.rdf)
• it has been suggested to move both files to github, but that's maybe not possible – firefox needs the header to be Content-type: text/xml for the update-beta.rdf file, which is (I think so) not possible on github.
  So what to do?
  Additionally, as soon as we have a stable version, it might be nice to have an own domain for PR (which might contain a forum). – no idea if we'll take over requestpolicy.com or if we'll have our own.

long version (so far)
This copy-pasted discussion is from https://github.com/RequestPolicyContinuedTmp/requestpolicy/commit/d7f4da7fbfbe2abbc82f372e61b9ee848fc60870#commitcomment-7408303
(I'm posting it here because I'll remove the RequestPolicyContinuedTmp organization soon.)

msxfm writes:

<em:updateURL>https://sslsites.de/requestpolicy.256k.de/update-1.x-beta.rdf.php</em:updateURL> (src/install.rdf)

Hi, can we host this on github please? Maybe using github releases https://github.com/blog/1547-release-your-software. Or store it directly in the dev-1.0 tree?

I'd prefer the manifest to stay alongside the source (at least same domain). Currently update-1.x-beta.rdf.php is not reviewable from the version control system and it's rather security critical.

myrdd:

yes, it would be ok for me to host the rdf on github, but will we upload the xpi files to github also? I would say we shouldn't use git to upload a completely new binary file every few days.
github releases, from what I've seen there, are bound to tags. Same as before, I don't want to create a mess by making a tag every few days.
In fact, I don't get your point, why do you want to have the rdf in the version control system?

nodiscc:

why do you want to have the rdf in the version control system?

• Because it's part of the code (though it's not in the final XPI)
• Does not depend on a third-party server that can go down, get compromised.. the repo can get compromised but we would likely notice.
• Changes in the repo are reviewable, we can see when/if/why it breaks. More portable, everyone can fork and add his own XPI url.
• will we upload the xpi files to github also

What I would do:

• wait before we complete the merge discussed in RequestPolicy#407 (comment)
• move update-1.x-beta.rdf from your server to the root of the repo.
• Change em:updateURL in src/install.rdf to https://github.com/RequestPolicyContinued/requestpolicy/blob/master/update-1.x-beta.rdf
• build the XPI.
• Create a release (for example 1.0.0b4-1), add the XPI as attachment. If you attach them to releases, they don't get in the git repo - they are just attached - you can attach an arbitrary binary file to each release. (example)
• Point em:updateLink in update-1.x-beta.rdf to your released XPI on Github.

You just have to repeat the 2 last steps for each release. We would have everything in the same place, source, update rdf, and XPI.

• Same as before, I don't want to create a mess by making a tag every few days.

You are not forced to tag and release every few days, just build the XPI on your side and release it when it's ready/working. Tags do not mess up anything, and the repo already has a few.

Thanks for your time on this.

myrdd:

Thanks for your detailed clarification, sounds reasonable and I agree.

About the tags: until now, I've pushed a new version with every interesting change or bugfix (maximum every day). Continuing like that, we could get a lot of tags. If this matters, we could decide to release beta versions less often. Can you suggest a common/best practice how often to release alpha/beta/stable versions?

nodiscc:

Yes, we have to think about a clean release process. This likely means a bit of branch cleanup/reordering. I'll think about it and add an issue at https://github.com/RequestPolicyContinued/requestpolicy

myrdd:

ok :) if you don't mind I'll call the next version 1.0.0b7, which will also be the tag's name (currently it's 1.0.0b6). This way, beta versions already installed will get updated also. ok?

myrdd:

I think there's a problem about hosting update.rdf on github. When you access a file, like this one (click here), then you'll get a plaintext file. – but: the webserver needs to send the HTTP header Content-type: text/xml, otherwise Firefox doesn't accept the update file. I had this issue when I tested that on my own server. So what to do? Host the xpi on github and host update.rdf externally?

[lofidevops]

This discussion is very educational re hosting builds on GitHub :)

Is it possible to provide Content-type: text/xml if you host the file on GitHub Pages rather than in the GitHub repo? (I couldn't find any indication either way - but since GitHub Pages can host a sitemaps.xml file maybe it's worth a try?)

[nodiscc]

firefox needs the header to be Content-type: text/xml

I's actually possible to serve text/xml content-type from github (I've set up an example here. File has to be in the gh-pages branch and would be accessible at https://RequestPolicyContinued.github.io/requestpolicy/update-1.x-beta.rdf

gh-pages should be created as an orphan branch (does not share history with another branch) and the file pushed there.

I can take care of creating the branch, and a very simple HTML homepage for the project (basically copy contents from https://requestpolicy.com there + add a link to the releases page). It would be at http://RequestPolicyContinued.github.io/requestpolicy

What do you think?

it might be nice to have an own domain for PR

This would require someone to host it (including costs and availability requirements). IMHO not very portable/practical, a better alternative is using Github Issues as a discussion means, and tag these threads as question. If a question is frequently asked, it can be added to the documentation (which we can setup on gh-pages or in the Github wiki)

So we can have code+update rdf+website+doc+forum on a single host, 2 commands away from a full backup/fork.

[nodiscc]

@kwill looks like we had the same idea about at the same time...

[myrdd]

What do you think?

great! Go ahead! 👍
So in gh-pages will be a html page(s) and the update-rdf-file(s), no?

We could create a custom subdomain, e.g. requestpolicy.github.io (if it's possible), then it's independant from the real organization's name "RequestPolicyContinued". Also, the name would be shorter. What do you think?

Yes, I think it's better to keep all discussion on this forum, at the moment.

[nodiscc]

So in gh-pages will be a html page(s) and the update-rdf-file(s), no?

Yes!

We could create a custom subdomain, e.g. requestpolicy.github.io

Not possible because requestpolicy.github.io is reserved for https://github.com/requestpolicy (original organization by @jsamuel). I think we can live with the current requestpolicycontinued.github.io until @jsamuel takes a decision (merge our changes, transfer ownership, whatever... if it's not possible then we can keep requestpolicycontinued as this will effectively be a separate project).

[myrdd]

ok.
btw/fyi, I thought it would be good to create a developer wiki, created a first page and then recognized that @jsamuel already created one. I'll try to collect my knowledge/experience there to make it easier for others to understand the code.

[nodiscc]

I have set up a homepage for the project, it is viewable at https://nodiscc.github.io/requestpolicy/

Feedback welcome, I'll push it to this repository when it's fine for everyone.

[myrdd]

Great! I will read it through. But I've already recognized that you make use of JavaScript. Please do not do that, especially not for the download button! If you need this for the contributors list, that's ok if this is the only possible way. But there is no contributors list yet, no?
Another point: please do not make any cross site requests. This would be ironic as we're offering a tool agains that. You can upload jquery.js on gh-pages as well.

As for the install button, you might do something like

<a><span>Download</span><span>addon for Mozilla Firefox</span></a>

and then define a and span as display: block in CSS, and add more styles. See also here.

[nodiscc]

I'd prefer it without js also. Fixing it asap.

There is a contributors list at https://nodiscc.github.io/requestpolicy/#about (right side) but it's quite empty - part of what I said in RequestPolicy/requestpolicy#407 (comment). So the about/credits/donations section is still undecided.

[nodiscc]

I did a bit of work on this, feel free to check.

[lofidevops]

Some suggestions:

• is it possible to explicitly license the documentation with a free license? (CC-BY, CC-BY-SA, FDL or similar) - if there is a problem in that it derives from the old project, it could also be licensed as GPLv3 (even though it isn't code) - the reason for suggesting this is that (to the best of my knowledge) groups like the FSF are happier to promote the project to users and developers if they are assured that the user documentation is also free
• under "Detecting RequestPolicy" there is a general link to "browser fingerprinting" - a link to EFF's Panopticlick may also be appropriate? https://panopticlick.eff.org (I'm happy to suggest wording if you like)
• but overall, it's great to see all this content so clearly laid out and not behind an expired certificate!

[nodiscc]

Hi @kwill , thanks for your feedback

• We have a problem with the docuentation license. The original doc on requestpolicy.com (which I copied and adapted to the new homepage) has no explicit license either (© 2008-2012 Justin Samuel at the bottom of the page...). I'm pretty sure @jsamuel wouldn't mind we copied it but we may want to ask him to relicense, for clarity (CC BY-SA and FDL are good Free documentation licenses). Justin may be hard to contact though.
• I had tried linking directly to panopticlick but the EFF page doesn't clearly explain (at first sight) what fingerprinting is about - which the wikipedia page does in the first lines). There's also a link to panopticlick on the wikipedia page (and other useful resources). Maybe a direct link can be added to the paragraph?
• The docs may need some reordering for better reading. https://github.com/RequestPolicyContinued/requestpolicy/blob/dev-1.0/README.md needs to be adpated too.

Anyone, feel free to submit changes/pull requests to the doc at https://github.com/nodiscc/requestpolicy

[myrdd]

• Copyright is a good point. We should contact him before making this site really public… Maybe with a friendly brief email to his company we'll get an answer? (It seems to be a small team.
• The page title: I would clearly state that this is the Continued project. I'd put that word in the red area, next to or under "RequestPolicy". Info about the differences between RP (requestpolicy.com) and RP-Continued should be stated as the very first FAQ answer.
• IMO the download should point to a stable release. I really don't consider 1.0 stable yet. Also I think it's better if the Download button links directly to the xpi file (as soon as we have one :) ) For the beta, I'd add a small link below the download button which leads to a heading in the page, containing info about the current development and a download link for the beta. -- I can take charge of those releases and the xpis.
• If we may keep the text, it needs some update before we release 1.0. For example in Which kinds of requests are blocked?, the default policy will change.

What do you think?

[myrdd]

I've made some changes to the readme in the (paragraphs on the very top). Could you please review them? Thanks.

[myrdd]

Justin may be hard to contact though.

@nodiscc did you try to contact him? I wrote two emails to him some weeks ago, but he didn't reply.

If he won't reply at all, what will we do? I think we shouldn't just copy his texts, because of:

© 2008-2012 Justin Samuel

But rewriting the text is quite some work…

[jsamuel]

Hi everyone,

I'm sorry for my lack of communication.

I would be very happy and quite relieved to put a single person in charge of RequestPolicy development, the GitHub organization, and the website. From there, they could organize other contributors as they see fit.

For good and hopefully obvious reasons, the big obstacle is trust.

Question: is there a single person here who everyone would want to see taking over the project and who wants to take over the project?

[myrdd]

Hi @jsamuel, I'm really happy to hear from you! Great to hear you're willing to help us continue the project! Of course I understand that trust is important for you, especially if you want to transfer both github project and website! It's up to you to decide. One idea could be to continue development on this repository (RequestPolicyContinued) for the time being. As soon as we reach a version which we consider as stable, you can take a look it and decide.

However you decide, I think I'm the only one developing (programming) RP at the moment – at least I don't know about anyone else. So in case you'd hand over development to me, that would be a great honor for me. But however you decide, I'll be happy developing RP.

About the website: I think it might be useful to move it to github, or to let the community work on it in any other way – but I'm uncertain about this.

[nodiscc]

Great to hear from you! Thanks for your work on RP, I've been using it for as long as I can remember, it's awesome.

Indeed there is a very valid trust question.

Easiest things first, Website: you can already pull my work from https://github.com/nodiscc/requestpolicy/tree/gh-pages to your gh-pages branch and be done with the website. Just replace requestpolicycontinued with requestpolicy everywhere - then maybe close https://www.requestpolicy.com/ and update https://addons.mozilla.org/en-US/firefox/addon/requestpolicy/ support link to your github project). I'd like to have the website+doc licensed under CC-BY-SA if you're OK.

For addon code, The way I'd prefer it to be:

• https://github.com/RequestPolicy/requestpolicy/ stays the official repo
• https://requestpolicy.github.io/requestpolicy becomes the official website
• you keep exclusive write access to the repo/site.
• You review and merge changes from RequestPolicyContinued/requestpolicy when you see fit.
• You create the https://github.com/RequestPolicy/issues repo (no code there, only bug tracker) and give me and @myrdd admin access on it so we can manage issues - we import our issues there (50 or so have been closed). You use this as only bug tracker (disable "issues" on the original RequestPolicy/requestpolicy, update readme pointing to RequestPolicy/issues)

Of course you may not have time or will to maintain RP anymore, in this case there are other options:

• Pull the website anyway, and update your README and website to say you're not maintaining RP anymore, with a link to the continued project. We can change project name if you like. Disable issues on your repo to prevent confusion.
• Or give @myrdd write access to your repo RequestPolicy/requestpolicy. I've reviewed his commits so far (subscribed to https://github.com://RequestPolicyContinued/requestpolicy/commits/dev-1.0.atom) but I could very well miss something malicious/broken now or later. Maybe we need to do some noise about the project to have more reviewers (eff.org, reddit, blog posts, i don't know). I don't need write access to the code, I'll submit pull requests if I need to.

What do you think?

@myrdd I've added a comment on ad5aaa2, can you check? (gh-pages is only for the site and update rdf, no binaries. Binaries go at https://github.com/RequestPolicyContinued/requestpolicy/releases)

[nodiscc]

I did some work on the website (see above commits)

IMO the download should point to a stable release. Also I think it's better if the Download button links directly to the xpi file

Linking directly to the xpi on github won't work (triggers a download dialog, not addon installation). The stable addon should be uploaded to addons.mozilla.org when it's ready. Then link to the xpi, or to the addon page.

I really don't consider 1.0 stable yet.

As long as you mark dev releases as "Pre-release" in the github releases pages I think it's fine. Proper, production-ready XPIs will appear in green, betas in orange. But we should upload this to addons.mozilla.org to keep it clean (and get rid of the above problem).

the default policy will change

Will update this when it's done, feel free to edit the doc - I will push it to gh-pages RequestPolicyContinued/requestpolicy as it's in good shape now, and @jsamuel seems to agree on the doc license.

[nodiscc]

website pushed at https://requestpolicycontinued.github.io/requestpolicy/, website link on https://github.com/RequestPolicyContinued/requestpolicy updated

[myrdd]

Looks good! Thank you for your work! What you've suggested about the xpi is ok for me.

[SkySkimmer]

On the website, there are broken sentences at the end of the 3rd and 4th paragraphs on clickjacking.

[nodiscc]

I've rewritten the site in Markdown to speed things up and make maintenance easier. Once it's complete, it will include contents of the website, the wiki, and some parts of the README that really belong in the documentation. Current status: https://github.com/nodiscc/rp-website/wiki. Then we can proceed to

1. Move this documentation to the project's wiki.
2. Generate static HTML from the markdown and upload it to the website repo (with some extra styling if needed, can be done easily with pandoc). The website would actually be a mirror of the wiki.

Remaining todo:

• move https://nodiscc.github.io/rp-website/tutorial.html
• move https://github.com/nodiscc/rp-website/blob/gh-pages/draft-tutorial.md
• fix formatting
• include relevant parts from https://github.com/RequestPolicyContinued/requestpolicy/blob/dev-1.0/README.md
• build and upload the new website's static HTML.

@myrdd are you ok with this? I think having everything in one place will be easier to maintain, and easier for users/contributors to look for info.

[myrdd]

I think it's a good plan to have everything in one place. Let me know when I should review something.

[nodiscc]

The project's website, wiki and README have been merged in https://github.com/nodiscc/rp-website/wiki.

• I'm working on a build script for markdown -> static HTML conversion using pandoc and a few custom CSS adjustments.

Any feedback on the wiki contents/layout is highly appreciated.

[nodiscc]

• There is still duplicate information at https://github.com/nodiscc/rp-website/wiki/FAQ#how-to-find-relevant-information-about-a-bug and https://github.com/nodiscc/rp-website/wiki/Contributing#testing-reporting-bugs--requesting-new-features

[nodiscc]

• I'm thinking about re-adding the current website's first section (screenshots and usage overview) at https://github.com/nodiscc/rp-website/wiki#what-does-requestpolicy-continued-do

[myrdd]

Any feedback on the wiki contents/layout is highly appreciated.

So far I've read the pages main, privacy, security and half of quickstart carefully. This is what I took note of:

general note

• I think we should speak of „RequestPolicy“ in most cases and shouldn't mention „Continued“. I was going to add a FAQ entry at least to the AMO description, which would be as follows:

Should „RequestPolicy“ from now on be called „RequestPolicy Continued“?

No, the addon may still be called „RequestPolicy“. The word „Continued“ has been added in some places in order to emphasize that there are two addons called „RequestPolicy“ on the web. As soon as the continued version has fully replaced the previous one, the word „Continued“ will be removed completely from the addon.

Still, the name of the project for now is „RequestPolicy Continued“, or „RPC“ for short..

So for example on the main page, I'd change „What does RequestPolicy Continued do?“ to „What does RequestPolicy do?“

pages

• main
  • the subscription link is dead
  • the link „0.5 version still available“ should point to https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/
• privacy
  • looks good!
  • maybe remove „Continued“ from the title
• security
  • maybe remove „Continued“ from the title (or correct the „COntinued“)
  • should the subtitles be headings?
  • I would add the following notice/warning at the very end of the page: When using RequestPolicy with the <a link to quickstart#default-policy>default policy</a> being „allow“, you won't be protected from the attacks/techniques described above!
• quickstart
  • the page's name contains .md
  • in „how RP works“, the order should be like the precedence, no? so (1) your policy, (2) subs, (3) default policy.
  • „subscriptions“ link is dead
  • the „rules“ link shouldn't contain .md

[myrdd]

I've accidentally pushed the submit button, but now my above comment is complete.

[DJ-Leith]

Any feedback on the wiki contents/layout is highly appreciated.

I agree with myrdd (just above).

In

https://github.com/nodiscc/rp-website/wiki/quickstart.md

(one of the 13 pages linked at the 'Top Right' of
https://github.com/nodiscc/rp-website/wiki )

In the section:

Allow requests to another.net: This will allow all requests to another.net, from any page, on any domain. This is not recommended unless you are tired to deal with many sites that require allowing requests to another.net.

My suggested wording would be to change the second sentence:

• Allow requests to another.net: This will allow all requests to another.net, from any page, on any domain. This is not recommended unless you keep having to allow requests to another.net from many sites.

I understand "you are tired to deal with" but I can't think how to put this is better English.

Note: Each action has a Temporarily block/allow alternative. This will add a temporary rule that will be removed when you click the Revoke temporary permissions menu item

• My suggested wording would be to expand this to become:

Note: Each action has a Temporarily block/allow alternative. This will add a temporary rule that will be removed when you click the Revoke temporary permissions menu item. When you close Firefox all temporary rules are forgotten.

---

Almost off topic - a question about RP rules and e10s: I'm not using e10s (because NoScript can't).

Will the RP rules be the same for ALL Tabs? I think they will.

With RP 0.5.28 and RPC 1.0.beta9.3 (and not using e10s) all Temporary Rules are applied (work) until they are revoked on all Tabs / Windows.

I very rarely add Rules - I nearly always use Temporary Rules.
In my usage these Temporary Rules are lost:

• usually when I close Firefox,
• sometimes when I click the "Revoke all temporary permissions" in the RP Menu,
• very rarely by using the UI to stop an individual Temporary Rule.

---

Back to 'quickstart.md page', at the end we have:

That’s it! Now you should be able to do most of the things RequestPolicy is built for. For more advanced topics, you can read the documentation below.

• Please provide a link to more advanced topics (there was no "below" - the text is at the bottom of the page).

[myrdd]

+1 for @DJ-Leith's suggestions.
However, note @DJ-Leith that the „Revoke temporary permissions“ button revokes all temporary rules as well. That is, clicking „Revoke temporary permissions“ or closing firefox do the same to temporary rules.

Hm, maybe the button should be renamed?
Now it's „Revoke temporary permissions“. My suggestion: „Revoke all temporary rules“.
So „all“ to clarify, and „rules“ because it's more appropriate.

---

about off-topic:

Will the RP rules be the same for ALL Tabs?

@DJ-Leith if this was your only off-topic question, the answer is yes.

[nodiscc]

@myrdd @DJ-Leith Thanks for your very useful review, everything you reported should be fixed. I'll work on it.

[DJ-Leith]

@DJ-Leith if this was your only off-topic question, the answer is yes.

Thanks for confirming, @myrdd.

myrdd said:

However, note @DJ-Leith that the „Revoke temporary permissions“ button revokes all temporary rules as well. That is, clicking „Revoke temporary permissions“ or closing firefox do the same to temporary rules.

Just to be clear, the word "all" is already in the 'link wording': I had previously said:

• sometimes when I click the "Revoke all temporary permissions" in the RP Menu,

Next is a screenshot of what I was describing:

On this Profile, used for the screenshot, the 'whitelist' does not have any "github.com".
I had 'Temporary allowed' all of the '6 green entries seen - to the githubusercontent subdomains etc'.
All of these will be revoked if I click the "Revoke all temporary permissions" link.

Hm, maybe the button should be renamed?
Now it's „Revoke temporary permissions“. My suggestion: „Revoke all temporary rules“.
So „all“ to clarify, and „rules“ because it's more appropriate.

In RPC 1.0.beta9.3, the 'option I was talking about', already has "all".
Perhaps there is another place where it does not have "all"?
If so, I would agree - add the word "all".

As for the 'rules vs permissions' question: I agree, be consistent and call them "Rules".
"Rules" (meaning in the "user.json" or other 'permanent storage file' used by subscriptions),
"Temporary Rules" that 'last until revoked by closing Firefox' - the session,
or by explicit revocation
e.g. by clicking the 'soon will be' "Revoke all temporary rules" link
(which is, at the moment, called "Revoke all temporary permissions").

They are called "Active Rules" in about:requestpolicy?yourpolicy
The Temporary ones are in the "Rule Set" called "Temporary".

So, "Rules" is used widely.

@myrdd, if you do change the wording to "Revoke all temporary rules" then
I recommend that @nodiscc should change the website page:

it is (see above):

Note: Each action has a Temporarily block/allow alternative. This will add a temporary rule that will be removed when you click the Revoke temporary permissions menu item

to become:

Note: Each action has a Temporarily block/allow alternative. This will add a temporary rule that will be removed when you click the "X" to Revoke the temporary rule (in about:requestpolicy?yourpolicy) or you click the "Revoke all temporary rules" link (see screenshot). When you close Firefox all temporary rules are forgotten.

It would be good to have screenshots to illustrate.

[myrdd]

In RPC 1.0.beta9.3, the 'option I was talking about', already has "all".
Perhaps there is another place where it does not have "all"?

Oops, that's right. So "all" doesn't need to be added.

---

Note: Each action has a Temporarily block/allow alternative. This will add a temporary rule that will be removed when you click the "X" to Revoke the temporary rule (in about:requestpolicy?yourpolicy) or you click the "Revoke all temporary rules" link (see screenshot). When you close Firefox all temporary rules are forgotten.

I think this is way too long…
The first sentence is OK, but then I suggest:

• A temporary rule is a rule that gets removed automatically when Firefox gets closed. You can also remove all temporary rules manually by clicking on "Revoke all temporary rules" in the menu.

Screenshot would be OK for me, but not necessary.

— That's just my two cents.

[nodiscc]

Sorry for the lack of updates, I'm short on time :/

I've added checkboxes for each point that needs action in the wiki, https://github.com/nodiscc/rp-website/wiki is world-editable, so anyone is free to edit it and I'll review changes after the fact.

[nodiscc]

Copied from #661 (comment):

• Make the 1.x beta download button yellow ()
• Subtitle this button with 1.0 is being actively developed, but due to some compatibility issues some users might not want to upgrade yet
• add a smaller (green) download button for 0.5 pointing to https://addons.mozilla.org/firefox/downloads/file/318770/requestpolicy_continued-0.5.29-sm+fx-linux.xpi in this section
• subtitle this button with old version repackaged for current Firefox

[myrdd]

I've added checkboxes for each point that needs action in the wiki, https://github.com/nodiscc/rp-website/wiki is world-editable, so anyone is free to edit it and I'll review changes after the fact.

Thanks for pointing that out!

Thanks also for your summary.

• My suggestion: it's more wise to link to https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/ instead of directly to the file. The version number might increase, no? If you think a direct link would be good, I'll try to remember to update the link.

[DJ-Leith]

@nodiscc in #665 I have posted some screenshots.
The URLs are 'automatically generated by Github', just right click and "Open Link in New Tab" to find the URL. Feel free to use (or ignore) any or all of them without any attribution - you have explicit permission. Feel free to crop them, resize them etc. I have also added text to explain what I did. This is 'full and long winded': I am writing for people who are unfamiliar with RPC.

[DJ-Leith]

nodiscc said:

Sorry for the lack of updates, I'm short on time :/

I appreciate that. You have still 'done plenty' in the last few days!

I've added checkboxes for each point that needs action in the wiki, https://github.com/nodiscc/rp-website/wiki is world-editable, so anyone is free to edit it and I'll review changes after the fact.

I was reluctant to 'mess up' your good work.

I did however make two changes to
https://github.com/nodiscc/rp-website/wiki/Quickstart

• Changed spelling "explicitly".
• Added "all" to "... click the Revoke all temporary permissions menu item ..." to match what the User sees.

I also saw that there are now two links, "For more advanced topics, you can read the documentation below" at the end for:

• Updating from RP 0.5.xx to RPC
• Using RequestPolicy with Default Deny and a short Whitelist

Thanks very much.

[nodiscc]

did however make two changes to https://github.com/nodiscc/rp-website/wiki/Quickstart

Go ahead, as I said I'm notified of changes through RSS (with full diffs). Thanks for your fixes @DJ-Leith

I'll do the button changes soon. The hard part is now to provide a conversion script for Github's wiki markdown -> HTML while preserving links, tables and other formatting, and optionally providing a prettier style than the default wiki style. I'll write a bash script that we could adapt to a Makefile (I'm very bad at makefiles).

[nodiscc]

The new website/wiki is live at https://requestpolicycontinued.github.io/ and https://github.com/RequestPolicyContinued/requestpolicy/wiki

Upload new website/wiki:
 * Base documentation is stored in markdown files
 * On RequestPolicy's github wiki, markdown files are rendered by the wiki engine
 * On requestpolicycontinued.github.io, static HTML documentation must be built using ./build.sh
 * Note that the images URLs in markdown should be absolute URLs, even if the image is in the _media/ directory of the repo. The path defaults to https://raw.githubusercontent.com/wiki/RequestPolicyContinued/requestpolicy/_media/
 * Note that some items in the markdown documentation are still written in plain HTML (notably, tables). CSS rules from _media/github-markdown.css, as well as many HTML tags (divs, spans..) do not render on github wiki. Check the commit message.

 * The update-1.x-beta.rdf should still be present in this repo
 * The master branch should push to both
   * master on https://github.com/RequestPolicyContinued/requestpolicy.wiki.git
   * gh-pages on https://github.com/RequestPolicyContinued/RequestPolicyContinued.github.io

You just have to run ./build.sh to build the website from github wiki's markdown files. The wiki and the website should be used as remotes for your local repository. Building static HTML requires pandoc.

Please review, report and fix any problem you may find. The wiki is world writable, just clone https://github.com/RequestPolicyContinued/requestpolicy.wiki.git, edit and push your changes, and I will gladly sync the changes to the website repo.

[myrdd]

wow @nodiscc great! Thank you for your effort!

A few questions:

• I guess it's you who updates the website's repo @ https://github.com/RequestPolicyContinued/RequestPolicyContinued.github.io/, no? You know that I still need to edit the xpi/update-1.x-beta.rdf file? I hope that won't cause conflicts, it's an important file.
• I've added some documentation to the wiki a few days ago, but I can't find it anymore. Did you change the wiki's commit history? It was a new section for "Unit Tests", the section was called "Marionette". Sadly I don't have an offline copy…
• Edit: I see you've rewritten the history of the website's git repo as well. Why?

[nodiscc]

You know that I still need to edit the xpi/update-1.x-beta.rdf file? I hope that won't cause conflicts, it's an important file.

I know that xpi/update-1.x-beta.rdf should be left untouched. The script does not alter this file.

I guess it's you who updates the website's repo

You can also update it anytime by git checkout the lastest wiki revision, running build.sh and pushing the changes to the website's repo.

I've added some documentation to the wiki a few days ago, but I can't find it anymore. Did you change the wiki's commit history? It was a new section for "Unit Tests"

:/ I was confident that I had the latest revision. It should still be in my reflog, I'll restore it ASAP.

I see you've rewritten the history of the website's git repo as well. Why?

I started a fresh branch (orphan) to keep a clean history of the new website. I will restore the old version to a separate branch legacy RequestPolicyContinued/RequestPolicyContinued.github.io#5

[nodiscc]

Issue list for the website/wiki moved to https://github.com/RequestPolicyContinued/RequestPolicyContinued.github.io/issues

[myrdd]

Alright @nodiscc, thanks for your quick reply!

I was confident that I had the latest revision.

Just speculating: maybe you have checked online the history of the „Home“ page instead of the complete history? The page-specific links are on each wiki page, whereas the latter link is more hidden. In any case, nevermind, just make sure to backup and re-check the current version the next time you'll be „overwriting“ a remote branch. Still, if you have the changes in your reflog, that would be great!

Issue list for the website/wiki moved to https://github.com/RequestPolicyContinued/RequestPolicyContinued.github.io/issues

Does this issue still have a purpose? If not, let's close it. :)