This quarter, I will be moving forward with a small team at Clallam Bay prison to attempt to have computer software students make open-source contributions in JavaScript. The team is not particularly strong technically, really needing more education before they could reasonably participate independently, but for political reasons I need to push forward with the open source contribution mechanism (which has been in the works for over a year) as soon as possible. To that end, I have identified certain categories of code improvement projects that could be accomplished by people who do not need a deep understanding of the overall code. Initially I had expected to only do this in the calendar code, as there is less controversy there of the long-term future of the code, and a more well-defined path to reaching agreement on what could be done. But it would be good to broaden that to mail and mailnews code as well. So what I am looking for here is agreement that these categories of code improvement would be welcome in other parts of the comm-central codebase, including at least the mail/ and mailnews/ directories: 1. Replace older prototype-based class definitions with ES6 classes. 2. Expand the eslint implementation that Philipp did last year for Calendar, to the other directories within comm-central. (See the directories listed in src/.eslintignore in comm-central) I'm hoping that the above issues are relatively non-controversial, so that I can assign students to these tasks without fear that they will be discouraged by internal conflict. Any disagreement with that? There are two additional areas I would like to pursue that I expect to be more controversial, and we'll discuss later when I have some specific technical approaches to suggest. They are: 3. Replace the various approaches to module management within Thunderbird code with ES6 modules (import and export). This would include not only Mozilla (jsm) modules, but also many <script> tags within XUL. 4. DeCOMtamination of JavaScript code. Although I managed to make a complex XPCOM strategy work in JsAccount, I came away convinced that this had too many gotchas to recommend to others. XPCOM in pure JavaScript code is useful as a method of clearly defining types, but there are other ways of accomplishing the same thing that are safer and more performant. :rkent

Nothing sounds very controversial to me. #3 may be a bit premature, if the support in core isn't good atm. You say they are not particularly strong technically yet. I assume you'd be the middle-man upping the code quality? I don't think our small student bugs so far have been very useful to the project. You can easily end up putting in more time telling how to do things than doing it your self if the contributor isn't strong enough.  -Magnus On 7/19/17 6:35 PM, R Kent James via Maildev wrote: > This quarter, I will be moving forward with a small team at Clallam > Bay prison to attempt to have computer software students make > open-source contributions in JavaScript. The team is not particularly > strong technically, really needing more education before they could > reasonably participate independently, but for political reasons I need > to push forward with the open source contribution mechanism (which has > been in the works for over a year) as soon as possible. > > To that end, I have identified certain categories of code improvement > projects that could be accomplished by people who do not need a deep > understanding of the overall code. Initially I had expected to only do > this in the calendar code, as there is less controversy there of the > long-term future of the code, and a more well-defined path to reaching > agreement on what could be done. But it would be good to broaden that > to mail and mailnews code as well. > > So what I am looking for here is agreement that these categories of > code improvement would be welcome in other parts of the comm-central > codebase, including at least the mail/ and mailnews/ directories: > > 1.    Replace older prototype-based class definitions with ES6 classes. > > 2.    Expand the eslint implementation that Philipp did last year for > Calendar, to the other directories within comm-central. (See the > directories listed in src/.eslintignore in comm-central) > > I'm hoping that the above issues are relatively non-controversial, so > that I can assign students to these tasks without fear that they will > be discouraged by internal conflict. Any disagreement with that? > > There are two additional areas I would like to pursue that I expect to > be more controversial, and we'll discuss later when I have some > specific technical approaches to suggest. They are: > > 3.    Replace the various approaches to module management within > Thunderbird code with ES6 modules (import and export). This would > include not only Mozilla (jsm) modules, but also many <script> tags > within XUL. > > 4.    DeCOMtamination of JavaScript code. Although I managed to make a > complex XPCOM strategy work in JsAccount, I came away convinced that > this had too many gotchas to recommend to others. XPCOM in pure > JavaScript code is useful as a method of clearly defining types, but > there are other ways of accomplishing the same thing that are safer > and more performant. > > :rkent > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net >

On 7/19/2017 2:25 PM, Magnus Melin via Maildev wrote: > Nothing sounds very controversial to me. #3 may be a bit premature, if > the support in core isn't good atm. > > You say they are not particularly strong technically yet. I assume > you'd be the middle-man upping the code quality? I don't think our > small student bugs so far have been very useful to the project. You > can easily end up putting in more time telling how to do things than > doing it your self if the contributor isn't strong enough. > > -Magnus Concerning the code quality issue, yes I would be an intermediary. Also I am looking for large projects (like these are) where a skill once learned could be cloned to many patches, rather than one-offs where I agree students are not good candidates historically. #3 is premature, but I did some experiments with it yesterday and it does work. I would need to do a demo of what the implementation would look like. #4 is also premature because we need to agree on how to capture the useful typing information in the current .idl files. The best solutions all require transpiling of code which there is quite a bit of opposition to. Maybe we could use something like Google Closure or Typescript with Jsdoc annotations, without using the transpiled output? But #3 and #4 are critical to my long-term hopes of devising coding patterns that would allow Thunderbird to work in a wide variety of contexts with a similar code base. Right now the assumption is that is not practical, but I would like to demonstrate what it would take, and hope that the resulting coding patterns would be acceptable. :rkent

As Magnus said, hold off on #3. For the other points , could you please give a concrete example which existing code you would format how? Details matter here, we care down to whitespace. This avoids that they reformat 20 classes and then have to change them all. I think it woukd be good to define the wanted format here, but as part of the review, as it sets the standard for all code. Ben Am 19. Juli 2017 23:25:57 MESZ schrieb Magnus Melin via Maildev <maildev@lists.thunderbird.net>: >Nothing sounds very controversial to me. #3 may be a bit premature, if >the support in core isn't good atm. > >You say they are not particularly strong technically yet. I assume >you'd >be the middle-man upping the code quality? I don't think our small >student bugs so far have been very useful to the project. You can >easily >end up putting in more time telling how to do things than doing it your > >self if the contributor isn't strong enough. > >  -Magnus > >On 7/19/17 6:35 PM, R Kent James via Maildev wrote: >> This quarter, I will be moving forward with a small team at Clallam >> Bay prison to attempt to have computer software students make >> open-source contributions in JavaScript. The team is not particularly > >> strong technically, really needing more education before they could >> reasonably participate independently, but for political reasons I >need >> to push forward with the open source contribution mechanism (which >has >> been in the works for over a year) as soon as possible. >> >> To that end, I have identified certain categories of code improvement > >> projects that could be accomplished by people who do not need a deep >> understanding of the overall code. Initially I had expected to only >do >> this in the calendar code, as there is less controversy there of the >> long-term future of the code, and a more well-defined path to >reaching >> agreement on what could be done. But it would be good to broaden that > >> to mail and mailnews code as well. >> >> So what I am looking for here is agreement that these categories of >> code improvement would be welcome in other parts of the comm-central >> codebase, including at least the mail/ and mailnews/ directories: >> >> 1.    Replace older prototype-based class definitions with ES6 >classes. >> >> 2.    Expand the eslint implementation that Philipp did last year for > >> Calendar, to the other directories within comm-central. (See the >> directories listed in src/.eslintignore in comm-central) >> >> I'm hoping that the above issues are relatively non-controversial, so > >> that I can assign students to these tasks without fear that they will > >> be discouraged by internal conflict. Any disagreement with that? >> >> There are two additional areas I would like to pursue that I expect >to >> be more controversial, and we'll discuss later when I have some >> specific technical approaches to suggest. They are: >> >> 3.    Replace the various approaches to module management within >> Thunderbird code with ES6 modules (import and export). This would >> include not only Mozilla (jsm) modules, but also many <script> tags >> within XUL. >> >> 4.    DeCOMtamination of JavaScript code. Although I managed to make >a >> complex XPCOM strategy work in JsAccount, I came away convinced that >> this had too many gotchas to recommend to others. XPCOM in pure >> JavaScript code is useful as a method of clearly defining types, but >> there are other ways of accomplishing the same thing that are safer >> and more performant. >> >> :rkent >> >> >> _______________________________________________ >> Maildev mailing list >> Maildev@lists.thunderbird.net >> >http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net > >> > >_______________________________________________ >Maildev mailing list >Maildev@lists.thunderbird.net >http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net -- This email was sent from my phone. Please excuse the brevity

You can define interfaces in pure Javascript trivially, by declaring the class. E.g. you define the JS class Account, with comments and all, in its own file, then subclass it for the concrete implementations. Am 19. Juli 2017 23:41:44 MESZ schrieb R Kent James via Maildev <maildev@lists.thunderbird.net>: >On 7/19/2017 2:25 PM, Magnus Melin via Maildev wrote: >> Nothing sounds very controversial to me. #3 may be a bit premature, >if >> the support in core isn't good atm. >> >> You say they are not particularly strong technically yet. I assume >> you'd be the middle-man upping the code quality? I don't think our >> small student bugs so far have been very useful to the project. You >> can easily end up putting in more time telling how to do things than >> doing it your self if the contributor isn't strong enough. >> >> -Magnus > >Concerning the code quality issue, yes I would be an intermediary. Also > >I am looking for large projects (like these are) where a skill once >learned could be cloned to many patches, rather than one-offs where I >agree students are not good candidates historically. > >#3 is premature, but I did some experiments with it yesterday and it >does work. I would need to do a demo of what the implementation would >look like. > >#4 is also premature because we need to agree on how to capture the >useful typing information in the current .idl files. The best solutions > >all require transpiling of code which there is quite a bit of >opposition >to. Maybe we could use something like Google Closure or Typescript with > >Jsdoc annotations, without using the transpiled output? > >But #3 and #4 are critical to my long-term hopes of devising coding >patterns that would allow Thunderbird to work in a wide variety of >contexts with a similar code base. Right now the assumption is that is >not practical, but I would like to demonstrate what it would take, and >hope that the resulting coding patterns would be acceptable. > >:rkent > >_______________________________________________ >Maildev mailing list >Maildev@lists.thunderbird.net >http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net -- This email was sent from my phone. Please excuse the brevity

Typo. I meant: *not* as part of the review. Sorry. Am 20. Juli 2017 00:56:35 MESZ schrieb Ben Bucksch <ben.bucksch@beonex.com>: >As Magnus said, hold off on #3. > >For the other points , could you please give a concrete example which >existing code you would format how? Details matter here, we care down >to whitespace. This avoids that they reformat 20 classes and then have >to change them all. > >I think it woukd be good to define the wanted format here, but as part >of the review, as it sets the standard for all code. > >Ben > >Am 19. Juli 2017 23:25:57 MESZ schrieb Magnus Melin via Maildev ><maildev@lists.thunderbird.net>: >>Nothing sounds very controversial to me. #3 may be a bit premature, if > >>the support in core isn't good atm. >> >>You say they are not particularly strong technically yet. I assume >>you'd >>be the middle-man upping the code quality? I don't think our small >>student bugs so far have been very useful to the project. You can >>easily >>end up putting in more time telling how to do things than doing it >your >> >>self if the contributor isn't strong enough. >> >>  -Magnus >> >>On 7/19/17 6:35 PM, R Kent James via Maildev wrote: >>> This quarter, I will be moving forward with a small team at Clallam >>> Bay prison to attempt to have computer software students make >>> open-source contributions in JavaScript. The team is not >particularly >> >>> strong technically, really needing more education before they could >>> reasonably participate independently, but for political reasons I >>need >>> to push forward with the open source contribution mechanism (which >>has >>> been in the works for over a year) as soon as possible. >>> >>> To that end, I have identified certain categories of code >improvement >> >>> projects that could be accomplished by people who do not need a deep > >>> understanding of the overall code. Initially I had expected to only >>do >>> this in the calendar code, as there is less controversy there of the > >>> long-term future of the code, and a more well-defined path to >>reaching >>> agreement on what could be done. But it would be good to broaden >that >> >>> to mail and mailnews code as well. >>> >>> So what I am looking for here is agreement that these categories of >>> code improvement would be welcome in other parts of the comm-central > >>> codebase, including at least the mail/ and mailnews/ directories: >>> >>> 1.    Replace older prototype-based class definitions with ES6 >>classes. >>> >>> 2.    Expand the eslint implementation that Philipp did last year >for >> >>> Calendar, to the other directories within comm-central. (See the >>> directories listed in src/.eslintignore in comm-central) >>> >>> I'm hoping that the above issues are relatively non-controversial, >so >> >>> that I can assign students to these tasks without fear that they >will >> >>> be discouraged by internal conflict. Any disagreement with that? >>> >>> There are two additional areas I would like to pursue that I expect >>to >>> be more controversial, and we'll discuss later when I have some >>> specific technical approaches to suggest. They are: >>> >>> 3.    Replace the various approaches to module management within >>> Thunderbird code with ES6 modules (import and export). This would >>> include not only Mozilla (jsm) modules, but also many <script> tags >>> within XUL. >>> >>> 4.    DeCOMtamination of JavaScript code. Although I managed to make >>a >>> complex XPCOM strategy work in JsAccount, I came away convinced that > >>> this had too many gotchas to recommend to others. XPCOM in pure >>> JavaScript code is useful as a method of clearly defining types, but > >>> there are other ways of accomplishing the same thing that are safer >>> and more performant. >>> >>> :rkent >>> >>> >>> _______________________________________________ >>> Maildev mailing list >>> Maildev@lists.thunderbird.net >>> >>http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net >> >>> >> >>_______________________________________________ >>Maildev mailing list >>Maildev@lists.thunderbird.net >>http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net > >-- >This email was sent from my phone. Please excuse the brevity -- This email was sent from my phone. Please excuse the brevity

> I don't think our small student bugs so far have been very useful to the project. You can easily end up putting in more time telling how to do things than doing it yourself if the contributor isn't strong enough. Even if it does end up taking more time to help somebody contribute, than to make that contribution oneself, there is value in helping more people contribute. If we don't spend time mentoring new contributors, then we'll never have any new contributors. -- Tom

Agreed. However, that requires that the trainee stays with the project and becomes productive. I found that most student projects are a one way street. The trainee should a) already be at a certain level, and b) manifest interest in contributing long term. If that's given, then training is very helpful, yes. Am 20. Juli 2017 01:02:54 MESZ schrieb Tom Prince via Maildev <maildev@lists.thunderbird.net>: >> I don't think our small student bugs so far have been very useful to >the >project. You can easily end up putting in more time telling how to do >things than doing it yourself if the contributor isn't strong enough. > >Even if it does end up taking more time to help somebody contribute, >than >to make that contribution oneself, there is value in helping more >people >contribute. If we don't spend time mentoring new contributors, then >we'll >never have any new contributors. > >-- Tom -- This email was sent from my phone. Please excuse the brevity

Yes, certainly it doesn't always pay off. But I think it is probably hard to tell in advance when it will pay off and when it won't. In any case, I think rkent's main purpose is to help the students and the benefit to Thunderbird is mostly a bonus. On Wed, Jul 19, 2017 at 5:14 PM Ben Bucksch <ben.bucksch@beonex.com> wrote: > Agreed. However, that requires that the trainee stays with the project and > becomes productive. I found that most student projects are a one way street. > > The trainee should a) already be at a certain level, and b) manifest > interest in contributing long term. If that's given, then training is very > helpful, yes. > > Am 20. Juli 2017 01:02:54 MESZ schrieb Tom Prince via Maildev < > maildev@lists.thunderbird.net>: >> >> > I don't think our small student bugs so far have been very useful to >> the project. You can easily end up putting in more time telling how to do >> things than doing it yourself if the contributor isn't strong enough. >> >> Even if it does end up taking more time to help somebody contribute, than >> to make that contribution oneself, there is value in helping more people >> contribute. If we don't spend time mentoring new contributors, then we'll >> never have any new contributors. >> >> -- Tom >> > > -- > This email was sent from my phone. Please excuse the brevity >

Regarding the technical details of the plans, I don't have much to add, being unfamiliar with most of the codebase. However, given that we need to decouple ourselves from the firefox codebase, I think that anything to modernize the codebase and stop using mozilla-specific features is a good thing. As to linting, LINT ALL THE THINGS (or, even better, autoformat them if possible). I don't think the specifics matter all that much. -- Tom