Right now we use the permalinks https://www.mumble.info/LICENSE and https://www.mumble.info/AUTHORS in our LICENSE.header, LICENSE, AUTHORS, etc. to point people to an up-to-date LICENSE or list of authors.

Ideally, we would want this to be automated somehow. Already now, we're forgetting to update these files on the live site.

Now that we use Hugo, the "obvious" way would be to just include them statically. But I worry that they'll grow stale.

Can we do something dynamic here? Obviously, we could write a simple server for our Hugo site, which has dynamic handlers for /LICENSE and /AUTHORS.

Thoughts? /cc @bontibon

Context: I went to mumble.info to donate $$ to the project, but I couldn't find the donate button. First I looked down the center column, then down the right column, then down the left column. Then I did a ctrl+f to search for "donate" on the page. Clearly my eyes had missed the link in the left column. Perhaps because is undifferentiated from the rest of the content on the page!

Feature:

Place a "Donate" link with large text at the top center of the mumble.info home page. Include a "Paypal" icon so people immediately associate this link with the concept of payment. A

lternative position: duplicate the "Download mumble" column with a "Donate to mumble" column above, so users must browse past the donate section every time they download.

This section could include information about who receives the donations and what they are spent on. Project productivity statistics could be included here as well, such as: active developers, bugs fixed recently, release cadence, and importantly, SERVER COSTS! :)

Opening https://mumble.info/ asks for a user certificate, which it should not.

Opening https://www.mumble.info/ does not.

Note that for me it asks only once. When I cancel, opening it again does not again. In Firefox. I guess because it remembers.

Opening a new private browser windows the issue occurs again. Opening another private tab or window does not. But closing and opening a new private browser window, it occurs again.

Intro to our different types of configuration

OS X is called macOS since version 10.12.

Maybe the download page should reflect that?

I just found https://mumble-protocol.readthedocs.io/en/latest/index.html which I think should definitely be linked from the mumble-webpage.
I'm not sure if this is already the case (if so, just close this issue), but I wanted to throw this in here anyways :)

Add some intro like we have on our wiki landing page

For nice embed-previews on other platforms linking to us

In which build system (we have to trust) do we want to do this?

Related to or depends on #33.

We should add a Downloads page to the site.

The front page should include the most obvious download a user would want.
But we should have a separate page as well, to allow people to download specific products.

Such a page should encompass what's currently handled by the wiki's Download and Third Party Applications sections:

We have https://www.mumble.info/security for a list of published security vulnerability information which we link to from nowhere atm afaik,
and I added /.well-known/security.txt which has contact information.

Both should be reachable from the homepage/wiki.

See also #18; we could add our GPG sign keys for builds/releases on the topic of security, maybe add some information about security measures in use by Mumble itself.

Content like on this wiki page or a link to that page.

Or move from wiki to this site.

https://wiki.mumble.info/wiki/Contributing

https://gohugo.io/content-management/shortcodes/

There may be a better way doing this. For example on Wiki systems this is called "interwiki link".

Instead of using 100 times "https://wiki.mumble.info/abc/def" on the blog we can use something like "/abc/def".

When the wiki URL is changed in the future we only need to update the "interwiki link" once.

When I try to access "https://www.mumble.info", I get redirected to https://wiki.mumble.info/ and with the following message on the website:

[98cdf49479bdd8e33a18cfcf] 2018-06-16 19:37:46: Fatal exception of type InvalidArgumentException

and nothing else. 0 cookies placed.

We should use a real server example with some channels and users, channel comments and a welcome message instead of an empty client window.

I set up a special server for such purposes once and used that server for the screenshots of Mumble skins, see for example https://wiki.mumble.info/images/6/6b/Metromumble_light_preview.png

I could also add few fake users.

https://wiki.mumble.info/wiki/BuildingWindows_(deprecated)

Checkout the Mumble Qt git repo to C:\dev\QtMumble:

cd c:\dev
git clone git://gitorious.org/+mumble-developers/qt/mumble-developers-qt.git QtMumble

This git link is invalid. Can anyone could provide valid git link? Thanks.

with filters... and mumble-urls

I think its too much to have the Mumble logo on the top AND also in every article.

Probably needs custom markdown rendering that includes the link, and CSS to hide it by default but show it on hover.

Once the new site goes live, we'll need redirects in place from the old Wordpress blog.

It'd be cool if we could if we could prepare something we could use for that migration.
I'm thinking it's probably going to be a list of mod_redirect statements we can drop into the original host for blog.mumble.info -- at least to begin with.

Any takers? :)

See https://travis-ci.org/mumble-voip/mumble/jobs/332076111

We now get the following error:

E: Failed to fetch https://dl.mumble.info/mirror/pkg.mxe.cc/repos/apt/debian/pool/main/m/mxe-i686-w64-mingw32.static-gnutls/mxe-i686-w64-mingw32.static-gnutls_3.5.8-20170208_amd64.deb  503  first byte timeout

which is odd to me. I guess it means that our origin is too slow at serving the file to Fastly? Or maybe its our internal Varnish?... Not sure yet.

under "Download Mumble" section add link to the snap store https://snapcraft.io/mumble

1.3.0 is already in the snap store

https://gohugo.io/templates/rss

At some point, we should probably look into translating the website.

How do we do that with Hugo?

How will our URLs look?

Etc.

oops

See the title above

Or are these pages necessary?

Someone else needs to make that decision.

Currently at https://wiki.mumble.info/ is

Sorry! This site is experiencing technical difficulties.

Try waiting a few minutes and reloading.

(Cannot access the database)

Please repair the database connection.

AppImage is available at https://github.com/mumble-voip/mumble/releases but any mention if it is missing on the download page at https://www.mumble.info/downloads/ and in the 1.3.0 release announcement.

We'll need to figure out how to host the new website before we can go live.

Our generated slice documentation has always been a very simple html file structure.

Ice 3.6 still contains the slice2html executable. Ice 3.7 does not and tells you to use doxygen, which supports slice.

See v3.6-Usingslice2html and v3.7 Using Doxygen for Slice Documentation.

The doxygen generated HTML documentation is a lot more complex and IMHO overkill, and reduces readability and discoverability instead of improving it.

We should explore and decide on how we want to handle this in the future. Possibly establish a (documented or automated) generation workflow.

Ice has moved from slice file and dynamic type usage to generated code for more languages (namely PHP as well). Arguably, the generated types are enough with a decent IDE. Although being able to link to types and read them without generated code available would be very useful at times.

This issue became apparent in #60.

Move https://github.com/mumble-voip/mumble-gpg-signatures/blob/master/gpg.txt to the new website? Probably more common than a github view.

I think Roboto Light is a bit too thin on Windows:

Especially when used in the footer.

Thoughts?

Is (markdown) content supposed to use level 1 or level 2 headings?

Only one h1 should exist. Which is used for the page title (and website header title).

Consequently, it should be h2s, right?

But that breaks the toc links because the list starts at level 2:

I was just checking out what you guys were doing and ran into an issue with the Makefile.

I fixed it with the following:

diff --git a/Makefile b/Makefile
index 62e594d..0d13e21 100644
--- a/Makefile
+++ b/Makefile
@@ -1,10 +1,12 @@
+VPATH = src
+
 all: public mumble-www package
 
 public: $(shell find hugo/ -type f)
        (cd hugo/; hugo)
 
 mumble-www: mumble-www.go githubcache.go snapshotcache.go config.go downloads.go programflags.go
-       (cd src/; GO111MODULE=on go build -o ../$@ $^)
+       (cd src/; GO111MODULE=on go build -o ../$@ $(^F))
 
 package: public mumble-www
        7z a mumble-www.7z public mumble-www

The rule prerequisites are not available in the current directory. I'm no make master, so I'm sure there's a more elegant solution than mine.

Once a commit or PR has been landed in master, the site should automatically update.
If we need to clear any caches, we should be able to do so, too.

Anyone can use those URLs on his website instead of changing them on every release.

Like this: https://www.natenom.com/getmumble/

Use Ansible or another config management system to setup the host that will run the website.

The goal would be to make it easy to stand up the website if the host underneath needs to be recreated.

I don't think this needed for release, but it would be a nice to have.

We need to add a page describing how to report security issues in Mumble to the new site.

It should live at /security, like the current page does:

https://www.mumble.info/security

We can probably re-use most of it as-is.