How about we add a link to the code of conduct and archives and then just make this the global template for all the lists? Or is the guidelines link too specific to users list?

I don't know that it's too specific. If there are parts that are, it's probably worth changing it to be more generic. I only suggested making it specific to the users list because I wasn't sure if all lists would want the extra footer text.

It looks like there are a few places where the guidelines are specific to the users list. And some of it is not terribly relevant to folks on the devel list or other more technical lists, but that could be moved elsewhere if it seems too out of place. Ideally the list guidelines would only include the basics and avoid being so large that no one reads the important parts like "don't top post" & "trim your quotes." (Of course, what I think are the important parts may be pointless to someone else.)

As I understand it, making this change site-wide would be done by placing the text in /var/lib/mailman3//templates/site/en/list:member:generic:footer.

I didn't notice in my initial text that the link to the guidelines now redirects to a shorter URL: https://fedoraproject.org/wiki/Mailing_list_guidelines. That does include a link to the code of conduct as well, so perhaps it's sufficient to add just the guidelines and the archive link? I'm not personally worried about adding both lines. (I still remember older list and usenet guidelines for keeping .sigs less than 4 lines and under 80 columns, but I'm old. :) )

From my short reading tonight, I think that ${hyperkitty_url} should provide a link to the archives. So something like this in /var/lib/mailman3/templates/site/en/list:member:generic:footer should do the trick:

_______________________________________________
$display_name mailing list -- $listname
To unsubscribe send an email to ${short_listname}-leave@${domain}
List Guidelines: https://fedoraproject.org/wiki/Communicate/MailingListGuidelines
List Archives: ${hyperkitty_url}

(With Fedora Code of Conduct: https://docs.fedoraproject.org/fedora-project/project/code-of-conduct.html included, optionally.)

Here is the change as a patch to the mailman role in ansible, in case it's helpful. Most importantly it uses the proper URL for the guidelines.

There's a shorter code of conduct link on getfedora.org:
https://getfedora.org/code-of-conduct.html

I'd be ok with your patch + that. ;)

We are however frozen for beta right now, lets apply this after freeze lifts. Unless there is some urgency here.

Now that the freeze is past, perhaps we can give this a try? Here's an updated patch with the code of conduct added:

Curiously, I noticed that in the footer of https://getfedora.org/code-of-conduct.html there's a link to the Code of Conduct at https://docs.fedoraproject.org/fedora-project/project/code-of-conduct.html. On the list guidelines page, there's another short URL linking to the code of conduct at http://fedoraproject.org/code-of-conduct (which redirects to the docs.fpo version). I like the formatting of the getfedora version the best, but I think the http://fedoraproject.org/code-of-conduct link would be the ideal short link if it redirected to the getfedora page. :)

Perhaps more bizarre is that https://getfedora.org/code-of-conduct is also configured to redirect to the docs.fpo version. Do you know if that's intentional or would it be welcome if I submitted a patch to change the target of those redirects to https://getfedora.org/code-of-conduct.html (they're configured in playbooks/include/proxies-redirects.yml).

Well, we missed nonfreeze... however, if you would be willing to mail your patch to the infra list as a freeze break I would be happy to +1 it. I am sure we could get another and get this done.

(finally) applied.

However, it doesn't seem to be taking effect. :broken_heart:

@abompard any ideas?

@kevin I'll check that out. Thanks for doing all this research (I confirm there's no other way to set that at the moment).

Ah yeah I found why, the file should have the .txt extention to be found. I'll fix the playbook and re-run.

Nice, thanks for finding that important detail @abompard! (The documentation didn't make that clear at all. ;))

I see that this is working. One thing which is not quite what we expected is that the ${hyperkitty_url} is a link to the message being sent rather than a generic link to the archives for the list. Perhaps we should adjust that to just link to the archives? I'm not sure if there's a single variable for that or if we'd have to concat two of them to build it. A worst case of using multiple variables to build the archive URL might be https://${domain}/archives/list/${listname}. I'm sure there's a more suitable variable(s), but I don't know mailman3 well enough to find a list of available variables in the docs. Printing them from the mailman list object in a python shell might be the easiest way to get them?

I think the variable may be ${archiver_url}. (I wish the mailman docs made this easier to find. It doesn't seem like something I should have to dig through the source code to find -- and even then not be sure.)

Hmm no I don't think that ${archiver_url} will work. From looking at the code it does not seem that there is a variable available that will point to the list archive's top page unfortunately.
It would be a good thing to add though. I'll open a ticket upstream.

Thanks for looking and working with upstream on it @abompard. Odd that's not available. Until it is, perhaps we can just construct it ourselves from the variables which are available?

-List Archives: ${hyperkitty_url}
+List Archives: https://${domain}/archives/list/${listname}

Unless you think upstream will add a variable soon and we can either update or apply the patch to add the variable easily. Here it is in patch form, in case it's a worthwhile plan:

It would probably be ${fqdn_listname} and not ${listname}, and I'm not sure there is a ${domain} variable available. It may work with ${mail_host} because our mail host is also where the web archives are (but that would not be an upstream-compatible solution).

I went by http://mailman.readthedocs.io/en/latest/src/mailman/rest/docs/templates.html#templated-texts. If that's not accurate, then I'm more confused by the mailman3 documentation than I realized -- which wouldn't be shocking. ;)

I'm sure that ${domain} exists in that template context because we use it in the template already, along with ${short_listname}. That's what makes me think that ${listname} is available in the same context. If it's not somehow, ${short_listname}@${domain} could be used.

@abompard, when you have a moment can you let us know if the rationale in my previous comment is good? If so we can apply this patch and close this ticket.

I tried the patch, works fine. ;)

Thanks much for the patches and working through this!

:fireworks: