<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<i>I am referring to the Kitsune software that power the SUMO web
site in the line you say you do not understand.
<a class="moz-txt-link-freetext" href="https://github.com/mozilla/kitsune">https://github.com/mozilla/kitsune</a><br>
<br>
Given that Mozilla, with the help of the Lithium programmers,
could not make the in app links used by Firefox work reliably. I
do not see Thunderbird migrating to another platform. The
investment in time would be far better invested in fixing
Thunderbird bugs. The product and the platform (Thunderbird and
Kitsune) are just to tightly integrated for a new platform to be
lightly considered, no matter haw cumbersome Kitsune is. <br>
<br>
As for contributions, There is a lot of documentation on the site
which is maintained by the Firefox folks that describes the Wiki
markup, the tone of articles and a whole host more. This article
is a <a moz-do-not-send="true"
href="https://support.mozilla.org/en-US/kb/improve-knowledge-base">good
starting point</a> as it includes a full list of documents
designed to inform the new contributor with regard to technical
and policy per SUMO.<br>
<br>
I am asking what Thunderbird support documentation should look
like and how we are to keep it. There has always been a mozilla
poilcy not to write a manual, given we struggle to maintain some
knowledge base articles I am not in favour of a manual at this
time.<br>
<br>
Some of the policy type things I think that should be considered
are; <br>
<br>
</i>
<ul>
<li><i>Do we offer known addons in support articles to achieve
what the user is asking?</i></li>
<li><i>Do we offer documentation of CSS workarounds?</i></li>
<li><i>Do we support the use of userchrome? If so to what extent?</i></li>
<li><i>How will we get some sort of notification to the KB of GUI
changes? It is to late once the document is out of date. The
current arrangement appear to be someone notices say
addressing has changed and changes the articles they know of.</i></li>
<li><i>Do we offer more in KB article describing hidden prefs to
change the was the program works? I have started including
them because a failure to document what exists means they
really do not need to exist. But long standing policy is to
not include such information.</i></li>
</ul>
<i><br>
Some thing I would like to see in the longer term;<br>
<br>
</i>
<ul>
<li><i>Automated creation of a "set" of support images in a
variety of operating systems, this would include all of the
Icons used within the program.</i></li>
<li><i>Some sort of flag to be used in Bugzilla to notify of GUI
changes that require a knowledge base document update or a new
document.</i></li>
<li><i>Involvement of the development community in more than the
"release notes"</i></li>
<li><i>Sufficient information in the release notes to find the
bugs the change refers to. Documentation is quite difficult
in this product and finding the actual details without
consulting the source is sometime not possible.</i></li>
<li><i>Approval of bugs include consideration of user
documentation. V78 has pills. I have no idea how they work
really, and I have been following the bugs. Users will just
have to figure it out for themselves though as we have nothing
for them.</i></li>
</ul>
<p><i>But I want to see what the community thinks, this is supposed
to be a community driven project. I might be right off in my
thinking because of my user focus.</i></p>
<p><i><br>
</i></p>
<p><i>Matt</i><br>
</p>
<i><br>
<br>
</i>
<div class="moz-cite-prefix">On 14-Jul-20 7:11 PM, neandr wrote:<br>
</div>
<blockquote type="cite"
cite="mid:809ed392-b75e-1008-b5fe-3bfc17b28d12@gmx.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>An easy to access good (and most hopefully local language)
Support pages is a strong argument for new users but also for
current users. So Matt's call is a good approach.</p>
<p>I hope there are a lot of TB fans who would be willing to help.
But unfortunately the current pages are not very clear to give
this help, and the following lines are not helpful to understand
this. It would be helpful to be able to call up the current
tools. So potential helpers would be better able to estimate
their possibilities.<br>
</p>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Am 14.07.20 um 03:07 schrieb Matt
Harris:<br>
</div>
<blockquote type="cite"
cite="mid:8303add1-a719-2000-2f1a-a75d01e3414b@gmail.com"><font
face="Calibri">Clearly we are locked to SUMO as it is the only
workable location for in app links. Mozilla found that when
they tried to migrate to Lithium, so a new software solution
is not really an option. We are as wedded to Kitsune as we are
to the Mozilla platform, but other than the software used just
about everything about support documentation is open for
discussion.</font></blockquote>
</blockquote>
<br>
</body>
</html>