1. 24 May, 2019 2 commits
  2. 23 May, 2019 1 commit
  3. 22 May, 2019 1 commit
    • anonym's avatar
      TR instructions: ensure we fetch the final tag. · 97e678ab
      anonym authored
      The old instruction would not update the tag if it has been changed on
      the origin. Since we update rewrite the tag each release, there is a
      always a window where the TR can fetch a tag that will cause this
      problem.
      97e678ab
  4. 21 May, 2019 1 commit
  5. 20 May, 2019 1 commit
  6. 19 May, 2019 1 commit
  7. 18 May, 2019 1 commit
  8. 14 May, 2019 1 commit
  9. 10 May, 2019 1 commit
  10. 09 May, 2019 1 commit
  11. 08 May, 2019 1 commit
  12. 07 May, 2019 1 commit
  13. 06 May, 2019 3 commits
  14. 05 May, 2019 5 commits
  15. 30 Apr, 2019 1 commit
  16. 26 Apr, 2019 1 commit
  17. 17 Apr, 2019 2 commits
  18. 15 Apr, 2019 1 commit
    • intrigeri's avatar
      Clarify how to set the Assignee field when submitting a branch. · 1f5a8c4f
      intrigeri authored
      As Ulrike pointed out:
      
       - The previous phrasing was very unclear.
       - It's hard to guess whether the FT is able and willing to handle
         a given review. Better let them decide.
       - It's not obvious how one can try to find a reviewer by themselves;
         while regular contributors should hopefully have no trouble doing so,
         new contributors would be left in doubt.
      
      So let's make the default case "empty the Assignee field" and whoever
      is handling the FT's frontdesk role at a given time (for now: yours truly;
      some day: rotating role) will dispatch reviews adequately. And hopefully,
      other team leads have some kind of view that helps the detect pending
      reviews in their own area, without relying on the FT.
      
      refs: #16650
      1f5a8c4f
  19. 14 Apr, 2019 1 commit
    • intrigeri's avatar
      Add forms to search our public mailing lists on about/contact (refs: #9904). · 7b0d0340
      intrigeri authored
      Since more than 3 years, #9904 has been handled as part of #9900 ("Improve
      Website search"). I don't believe this approach is going anywhere because under
      the current assumption that our website must not use an external search engine,
      this would require ikiwiki to index the archive of our mailing lists. I don't
      think that's realistic (no progress on any of the ikiwiki-related subtasks
      of #9900 for years) and even if it were, I don't think it's a good use of our
      time.
      
      In the specific case of our public mailing lists, I believe we can skip the
      discussion about using an external search engine: our mailing lists are already
      hosted by a third party (Autistici/Inventati) and we already provide forms to
      subscribe to them, which POST to that third party. So adding another set of
      forms that POST to A/I's mailing list archive search engine does not make any
      difference in this respect.
      
      To improve UX, I'm using a placeholder that should help visitors of these web
      pages understand what the query string should look like (before they type
      anything), and a tiny bit of JavaScript that initializes the value to the
      required query prefix once the visitor has selected the search field.
      This requires disabling the htmlscrubber ikiwiki plugin on the affected pages.
      
      Finally, I'm wrapping these forms with <p>…</p>, otherwise the rendered layout
      is much too packed.
      7b0d0340
  20. 12 Apr, 2019 1 commit
  21. 09 Apr, 2019 2 commits
  22. 08 Apr, 2019 6 commits
  23. 05 Apr, 2019 4 commits