TB 78 Coming soon. The knowledge base needs you.
unicorn.consulting at gmail.com
Wed Jul 15 00:59:24 UTC 2020
/I am referring to the Kitsune software that power the SUMO web site in
the line you say you do not understand. https://github.com/mozilla/kitsune
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
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 good starting
point <https://support.mozilla.org/en-US/kb/improve-knowledge-base> as
it includes a full list of documents designed to inform the new
contributor with regard to technical and policy per SUMO.
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.
Some of the policy type things I think that should be considered are;
* /Do we offer known addons in support articles to achieve what the
user is asking?/
* /Do we offer documentation of CSS workarounds?/
* /Do we support the use of userchrome? If so to what extent?/
* /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./
* /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./
Some thing I would like to see in the longer term;
* /Automated creation of a "set" of support images in a variety of
operating systems, this would include all of the Icons used within
* /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./
* /Involvement of the development community in more than the "release
* /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./
* /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./
/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./
On 14-Jul-20 7:11 PM, neandr wrote:
> 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.
> 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.
> Am 14.07.20 um 03:07 schrieb Matt Harris:
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4066 bytes
Desc: S/MIME Cryptographic Signature
More information about the tb-planning