<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I figure I should throw in my two cents as I am running for the
Council and my name has been invoked .</p>
<p>please note that my dictations is getting bad sometimes and I
just can't correct everything going to get something out</p>
<p>so please ignore grammar and spelling issues:</p>
<p><b>Extension community and extension support:</b></p>
<p>this is the primary reason I am running, for a year and half I
have been attempting to be a semiofficial extension advocate</p>
<p>from my experience, communication with extension users and as
part of a general philosophy, I believe extensions</p>
<p>not only critical for Thunderbirds continuing success , 'are also
impacting users choice to a greater extent</p>
<p>then they are given credit for. It is an accepted principle in
product sales that many people make their decisions on features</p>
<p>available beyond what they might ever actually use. I have also
been working long enough to understand that</p>
<p>this perspective is not necessarily shared by all critical team
members. while having different opinions is to be expected,</p>
<p>I would consider this part of the Thunderbirds mission and if
people can't agree on the mission that a problem</p>
<p>as far as trying to improve this I would like to continue what
has been mentioned just started, recruiting extension developers.</p>
<p>I have actually quietly started this process a couple of months
ago and right now probably have at least one student who actually
could start.</p>
<p>making this activity more formal obviously makes sense, I believe
Ben said these people could potentially become core contributors</p>
<p>I totally agree with that. I would like to give you settings
under better circumstances which I hope will help with time and
everybody's</p>
<p>commitment to working better together.</p>
<p><br>
</p>
<p>I am just about finishing up my first WL -based conversion for
import-export-ng</p>
<p>I believe this is another good example of the utility of the API,
I have spent relatively little on the conversion with most of my
time dealing with separate bugs</p>
<p>the way I look at this is excuse us the opportunity in the form
of time to better determine our future and the creation of new
APIs.</p>
<p>the process for doing this should definitely be more open and I
am a total advocate of more not less where possible. I am not
totally afraid of change</p>
<p>but I am also absolutely against chasing the latest shining
object. Lastly I also think that along with agreement on the
mission I would like to see</p>
<p>more clarity from people both about our application being
distinct from a browser (it is basically immaterial we are based
on one) because I think that clarifies</p>
<p>that we need to look at certain things differently in terms of
functionality and how he allows users to do things or not.</p>
<p><br>
</p>
<p><b>Governance:</b></p>
<p>From the perspective of someone new, I believe many of the issues
mentioned lately really need to be fairlyin the camp of growing
pains.</p>
<p>I have experience in both a multibillion-dollar company where I
was hired after CEO level and experienced the wide range of
changes growing from</p>
<p>200M -> 2B . I have also had a startup I founded with all of
the issues one has the beginning.</p>
<p>I think there is general widespread agreement that there could be
some changes to improve process and transparency. I do not believe</p>
<p>in anyone's ill intent but probably more inexperience or lack of
clarity on how to deal with all the changes that have occurred
particularly this year.</p>
<p><br>
</p>
<p><b>Organization/NDA:</b></p>
<p>I am somewhat surprised / several of the comments relative to the
organizational entity and things like NDAs.</p>
<p>Thunderbird has money, employees as well as a myriad of
relationships both casual and contractually defined <br>
</p>
<p>it does not matter that we are a nonprofit or that we have many
volunteers other than complicating things.</p>
<p>bottom line is there's really no way to appropriately operate
without legal entity. I do believe would be worthwhile</p>
<p>For the community at large to better understand the new
organizational structure and operational aspects.</p>
<p>but this is a good example of something that requires someone's
time to do. We are all stretched thin.</p>
<p>on or off the Council, I would advocate for not only this better
understanding, but also some focus on</p>
<p>discussing the implication of this going forward for our
organization.</p>
<p><br>
</p>
<p>sorry if this is rambling, I figured people at least deserve to
know where I stood on some of these issues...</p>
<p>Christopher<br>
</p>
<br>
<div class="moz-cite-prefix">On 9/24/2020 3:19 PM,
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning-request@mozilla.org">tb-planning-request@mozilla.org</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:mailman.1028.1600975179.1048.tb-planning@mozilla.org">
<pre class="moz-quote-pre" wrap="">Send tb-planning mailing list submissions to
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
To subscribe or unsubscribe via the World Wide Web, visit
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
or, via email, send a message with subject or body 'help' to
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning-request@mozilla.org">tb-planning-request@mozilla.org</a>
You can reach the person managing the list at
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning-owner@mozilla.org">tb-planning-owner@mozilla.org</a>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of tb-planning digest..."
Today's Topics:
1. Re: Future mailing list communications changes (Juergen Fenn)
2. Re: Inclusion of the community in decisions (was: Thunderbird
Council Elections - Nomination Deadline: Tuesday, September 23,
2020) (Ben Bucksch)
3. Re: Addon transition support (was: Inclusion of the community
in decisions) (Ben Bucksch)
4. Re: Addon transition support (was: Inclusion of the community
in decisions) (Dirk Steinmetz (rsjtdrjgfuzkfg))
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Sep 2020 18:31:14 +0200
From: Juergen Fenn <a class="moz-txt-link-rfc2396E" href="mailto:jfenn@gmx.net"><jfenn@gmx.net></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
Subject: Re: Future mailing list communications changes
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:8f583269-c54f-23d2-0baa-f81e20a2efb8@gmx.net"><8f583269-c54f-23d2-0baa-f81e20a2efb8@gmx.net></a>
Content-Type: text/plain; charset=utf-8
Am 24.09.20 um 15:01 Uhr schrieb Patrick Cloke:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I believe Google Groups also lets you import members / doesn't require a
Google account, but it has been a while since I've managed any of those.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
That's right. I'm a list-owner of a Google group and I can subscribe any
email address to that list.
If Mozilla indeed does not keep running its mailing lists on their own,
I'd prefer to migrate the existing lists to our own mailman servers. I
am sorry to say that I would not follow you to Topicbox or whatever
service. Sad to see you go.
Regards,
J?rgen.
------------------------------
Message: 2
Date: Thu, 24 Sep 2020 19:13:23 +0200
From: Ben Bucksch <a class="moz-txt-link-rfc2396E" href="mailto:ben.bucksch@beonex.com"><ben.bucksch@beonex.com></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
Subject: Re: Inclusion of the community in decisions (was: Thunderbird
Council Elections - Nomination Deadline: Tuesday, September 23, 2020)
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:7431e6dc-d5f9-3b0d-cd9d-a10639d717c6@beonex.com"><7431e6dc-d5f9-3b0d-cd9d-a10639d717c6@beonex.com></a>
Content-Type: text/plain; charset=utf-8; format=flowed
Am 24.09.20 um 18:04 schrieb John Bieling:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I have said it before: We have no guarantee that the stuff I am using
in my WL API will remain. If some of that stuff is removed by m-c,
than the WL API will no longer work. I created it because so many
add-ons would have been lost or developers would have needed much more
time to convert and thus users would by unhappy again, that many of
their add-ons no longer work. But I said from the very beginning, that
the conversion process is not done with this first step, but just a
start for a series of little-step tutorials, which aim to be completed
on a rainy weekend each. The first tutorial is out, the second one is
in the making. In the end, the extensions should work without the WL API.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Thank you, John, for work like that! You have been a real help and hope
to extension developers.
We all understand that WindowListener is a band-aid, you made that very
clear from the beginning, and it's good that you did. Only Eyal doesn't
want to hear that, solely out of his principle. The rest of us
understood that you just tried to help in the short term.
I also appreciate that you make tutorials that help with the transition.
I'm sure many extension developers appreciate that. I also think that
your work has probably helped many extensions to survive. It is work
like that that I meant and I think should continue and intensify. Thanks
for your wonderful work, John.
Ben
------------------------------
Message: 3
Date: Thu, 24 Sep 2020 19:29:17 +0200
From: Ben Bucksch <a class="moz-txt-link-rfc2396E" href="mailto:ben.bucksch@beonex.com"><ben.bucksch@beonex.com></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
Subject: Re: Addon transition support (was: Inclusion of the community
in decisions)
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:fd43da94-fb83-6087-04dd-7c6008d1b26b@beonex.com"><fd43da94-fb83-6087-04dd-7c6008d1b26b@beonex.com></a>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Am 24.09.20 um 17:48 schrieb Wayne Mery:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
It's not very public but (for a year now?) we have been doing "finding
new volunteer owners for abandonned addons that are in active use".
Christopher kicked it off.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
That's great! I wasn't aware of that.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">But it's a struggle when (as we have from the beginning fo time IMO)
we're not starting with a cohesive (and happy and active) add-on
developer base, insufficiently documented or not yet discovered
solutions, and (from my perspective) a general reluctance of many
add-on developers to dig in and contribute to creating solutions -
like Christopher and John are doing.? They have put in massive time.?
Hats off to them and *_everyone else_* who is participating in that,.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Let me join that "Thank you!".
I think onboarding addon developers is also a great chance for the TB
project, because they might become core contributors. From addon to
WebExtension API implementation to core contribution is a fairly natural
path. People will stay depending on the experience they have - most
importantly, whether their ideas and patches are accepted or not.
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <a class="moz-txt-link-rfc2396E" href="http://mail.mozilla.org/pipermail/tb-planning/attachments/20200924/e0d2b158/attachment-0001.html"><http://mail.mozilla.org/pipermail/tb-planning/attachments/20200924/e0d2b158/attachment-0001.html></a>
------------------------------
Message: 4
Date: Thu, 24 Sep 2020 19:46:23 +0200
From: "Dirk Steinmetz (rsjtdrjgfuzkfg)"
<a class="moz-txt-link-rfc2396E" href="mailto:thunderbird-lists@rsjtdrjgfuzkfg.com"><thunderbird-lists@rsjtdrjgfuzkfg.com></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
Subject: Re: Addon transition support (was: Inclusion of the community
in decisions)
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:f7dfc6f9-4d0b-357d-b734-dfef1976b043@rsjtdrjgfuzkfg.com"><f7dfc6f9-4d0b-357d-b734-dfef1976b043@rsjtdrjgfuzkfg.com></a>
Content-Type: text/plain; charset=utf-8
Hi Eyal & everybody else,
This mail got very long, so a quick TL;DR upfront:
* Technically add-ons still have all features, but need major changes to
access them. We should keep it that way. There are good reasons for
the changes made, but of course there is always room to improve.
* The frustration arises from social problems instead: mistakes were
made regarding communication with add-on developers, mostly related to
timing. Thunderbird needs to regain lost trust here.
That's the important bit. For a much more verbose version, read on.
----
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">But that's simply false: It is an arbitrary choice that we are making
- to strip extensions of their privileges and not to offer a decent
loader. The alternative is so easy, that most of it can be
accomplished by a few thousand lines of JS thanks to John Bieling
("WindowListener").
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
It's not that simple.
While I agree that it would have been great to have John helping out
earlier and thus prepare more tools to help developers before the
release of 78, add-ons will still need to get converted to WebExtensions
at some point.
Maintaining compatibility loaders is an uphill battle. It might have
been possible for 78, but even then add-ons would need major updates to
remain compatible in other places (especially in the UI department, a
lot of XUL was replaced with HTML).
It is important to switch to a technology that can be maintained in the
long-term, without harming the core product. And given that Firefox
seems to be committed to WebExtensions and Experiments (although they
are disabled in their release builds of Firefox), that technology seems
to be a better fit for the future.
That being said, this does not impact functionality. Experiments can
still do *everything* legacy add-ons could do. While the method to
access things from an add-on changes, the amount of things accessible
remained the same.
This discussion is only about technical debt that we acquired over the
years and is now due all at once. Yes, the transition is disruptive and
causes development costs for all add-on developers. But I don't see a
good alternative. Starting earlier would have lessened the impact, sure,
but it is not useful to morn about past decisions.
I do, however, think we should publicly commit to keeping experiments
enabled in release builds. It is important to give add-on authors the
ability to access things we don't have APIs for, as APIs will never
cover every aspect of Thunderbird.
Of course, this commitment must not influence the decisions of core
developers: between major releases, the core team must be able to do any
change they deem necessary. If changes break experiments, it is the
add-on developers' job to fix that during the beta phase of the next
major release. Thunderbird should provide assistance for that, though,
such as documenting important changes and maybe even releasing helper
code to work around them ? I agree with Ben that looking at the
cumulative work is a good guideline when thinking about these things.
In effect, this means that add-on authors will still want to use APIs
when they are available. After all, the core team keeps these APIs
relatively stable, so add-ons relying on them only rarely need updates
to remain compatible. But if an add-on author wants to access an
additional feature here and there, there are options to do that with a
bit more effort.
That way, we can preserve the unique expandability of Thunderbird
without preventing major changes in the core ? which are necessary, both
for innovation and to keep up with the changes from Firefox.
So much for the technical part. So why do add-on developers and users
complain so much? I think the real issue is a social one: during the
pre-release phase of 78, add-on developers did not receive much support.
While it was not as bad as with Firefox Quantum, it did occasionally
feel like add-ons are an afterthought, and not a core part of the
mission. This is bad, because it discourages developers from going the
extra mile.
Given that I have a commercial interest in my add-on, I did invest a few
weeks of full-time work reading Thunderbird and Firefox source code, to
figure out how to structure the transition for my add-on. It is not
realistic to request that level of effort from open source developers.
I tried to reduce the amount of work others need to go through by
documenting the most important findings (together with others, of
course, most notably John) ? but even after understanding the technology
the migration to WebExtensions is an enormous task.
The solution seems to be to split that task into smaller parts: the
WindowListener experiment permits a relatively fast migration option to
get add-ons running in Thunderbird 78, without properly migrating them.
The plan is to have tutorials to do the migration is smaller steps, one
component at a time. This makes the update manageable for developers
that work in their free time, and thus ensures that developing add-ons
remains accessible.
The problem is that that solution is a relatively recent thing. Before
the WindowListener experiment was ready to use, Thunderbird 78 was
released. Users upgraded (although automatic updates were disabled) and
lost their add-ons. Developers tried to help them, but could not afford
the time for a proper migration. So both users and developers became
frustrated. In my humble opinion, this is the main takeaway from the
story: we should aim to have migration paths before releasing new
versions. This is absolutely essential for add-on developer retention.
We need to make add-on developers feel included. They need to be able to
trust the project to have their backs ? that trust was violated when 78
was released without properly communicated migration paths and now needs
to be regained. Clearly committing to keeping experiments in the
long-term would be a great political signal to support that.
It's a social problem. We cannot solve that with technology alone. But
if we solve it, I believe there is a chance to revive the whole
ecosystem. And I'm very happy with the effort I'm seeing so far ? from
John, Christopher, Philipp and probably others that I missed (sorry,
you're great too!).
I'm optimistic things will turn out ok.
Kind regards,
Dirk / rsjtdrjgfuzkfg
Am 24.09.20 um 10:01 schrieb Eyal Rozenberg:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
On 24/09/2020 2:51, Andrei Hajdukewycz wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I'm sure Wayne meant client/core developers.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Well, that's not what Wayne said. And if that's what he meant, this
illustrates how us extension developers are semi-consciously thought of
as inconsequential, not peers who must be part of decision making; and
that IMHO? is the result of a failure of leadership.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I don't know why the same
people keep trying to re-litigate this,
transition to web extension APIs
was guaranteed to happen in Thunderbird the moment Mozilla decided
that's the way Firefox was going. We delayed it as long as reasonably
possible. More than reasonably, IMO.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Until a couple of months ago, I was sure you were right: It's something
that just happens to us, out of our control, a done deal, Firefox forced
our hand etc.
But that's simply false: It is an arbitrary choice that we are making -
to strip extensions of their privileges and not to offer a decent
loader. The alternative is so easy, that most of it can be accomplished
by a few thousand lines of JS thanks to John Bieling ("WindowListener").
Also, there is no such thing as "transition". It's a cancellation of
extensibility. That is terrible and unacceptable. I hope we can overturn
this after the elections.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Unless you want to argue for rebuilding Thunderbird on some other engine
it was never going to be possible to make them work forever.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Again, this is simply untrue. (Almost) all we are missing is a facility
for loading extensions within Thunderbird. Our regular, non WE
extensions work just fine in Thunderbird 78 once we've loaded them. With
a little bit of effort we would probably just be able to load
chrome.manifest-based extensions (perhaps with some tweaks).
We are wasting everybody's time and resources with replicating APIs and
making people rewrite their extension code when this is absolutely not
necessary.
Eyal
PS - Some new APIs may not be a bad idea, but they should not be about
what extensions are and aren't allowed to run.
_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
------------------------------
Subject: Digest Footer
_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
------------------------------
End of tb-planning Digest, Vol 127, Issue 47
********************************************
</pre>
</blockquote>
</body>
</html>