One more idea: the rule editor is now a bit hidden, I don't know how many visits it has. It could be made more visible/accessible, and have a verification step at the end, something like two buttons saying: Yes, this rule works for me / Cancel this rule. If the user clicks Yes, the page could submit the rule for the language maintainer for review, who could include it in the main rules if he sees fit.
On Tue, Dec 8, 2015 at 7:58 PM, Fekete, Róbert <robert.fek...@balabit.com> wrote: > > Hi, > > First of all, thank you very much for creating and developing this awesome > tool! > > My thoughts are in-line. > > On Mon, Dec 7, 2015 at 2:56 PM, Daniel Naber < > daniel.na...@languagetool.org> wrote: > >> Hi, >> >> the year is slowly coming to an end, so I thought I'd try to summarize >> what we've achieved this year and how we can move LT forward in the future. >> In 2015, we... >> >> * made three releases so far (2.9, 3.0, 3.1), another one is planned >> * more than doubled the number of visits to languagetool.org (January: >> 156,000, November: 326,000) >> * released a Chrome extension with more than 1,500 users now >> * added support for ngram models to detect confusion of (mostly) >> homophones (English, German) >> * did several things I forgot to list here >> * added and improved many language-specific rules. Specifically, 14 >> languages are maintained if you define this as "had at least ten commits in >> its grammar.xml and disambiguation.xml files this year". However, this also >> means 17 languages are not maintained. >> >> This last point of unmaintained languages highlights what I think is an >> important issue: In the last three years, we increased our number of users >> by a factor of 10. At the same time, the number of commits and people who >> regularly contribute didn't grow at all (see attachment). Many languages >> are not maintained, and even those that are often only have a single >> contributor. If that contributor becomes inactive, finding a new one seems >> almost impossible. If we continue like this, LT will some day end up with >> very few languages that are actually maintained. As there doesn't seem to >> be any correlation between number of users and number of regular >> contributors, user growth won't help us. >> >> I have no solution for this problem, but some ideas I'd like to get >> feedback on: >> >> (1) Clean up: throw out all unmaintained languages that also have less >> than 100 rules. This way users don't get the false impression that their >> language is supported when it actually isn't. It might also create some >> motivation to contribute when users notice that "their" language is being >> thrown out. >> > > Instead of throwing out, you might try to move them into a separate > repository/package/whatever, that can be downloaded/enabled separately - > maybe after a warning that these rules do not cover too many problems. > >> >> (2) Grow the contributor community: somehow find new contributors to >> revive the unmaintained languages and find contributors to support the >> maintainers of languages that are already doing well. The thing is: I have >> no idea how to do this. For example, we have a text on languagetool.org >> saying we're looking for help with marketing. This text has been shown to >> more than 40,000 visitors and the effect so far has been zero (actually >> four people have contacted me, but three of those have already >> disappeared). What is holding people back from becoming a regular >> contributor? >> > > Getting contributors is always difficult, there are much more people that > simply want to use a product. You might find some ideas in the book of Jono > Bacon, former community manager of Ubuntu: > http://www.artofcommunityonline.org/ > * turn feature development into smaller projects, that can be done as > part of a diploma thesis, and somehow have it available for students at > local universities > * another option might be to submit project ideas to Google Summer of > Code (though the chances of having them accepted might be slim) > * you could try to contact the localization groups of > Openoffice/Libreoffice, and try to convince them to include Languagetool in > their localized distribution, and to write the missing rules for it, or > maintain the existing ones. > > > > >> >> (3) Crowdsourcing: give up on finding qualified contributors, instead >> develop tools that allow contribution via very, very simple means, like >> clicking on correct and incorrect sentences. It's not clear how well this >> could work. It might be combined with (4). >> > > That might work as well, especially if somehow it could be turned into a > game. (No idea how.) Another possibility could be to have a very simple way > to submit custom rules (for example, if languagetool app would periodically > "phone home" to check for a new version - many software does that - and > would also display a note to the user if he has custom rules, encouraging > him/her to submit them for review.) > > > >> >> (4) Statistics: give up on finding qualified contributors and find errors >> using ngram statistics etc. With statistics, finding errors is >> language-independent. Quality might be worse than with hand-written rules, >> but for languages that are not maintained anyway there are often hardly >> hand-written rules. Of course, everybody could still contribute manually >> written rules and maybe revive language support that way. >> >> (5) Business: develop a business model and pay people for working on LT. >> This is difficult, developing a business is a full-time job on its own. >> Even if it worked, it would only cover very few mainstream languages. >> >> That might be possible - Languagetool is suitable for using rules > customized for specialized rules to comply with local styleguides and such. > If someone offers this as a consulting/integrating service, there might be > business in it. > > Actually, there might be people who already do this, you just don't know > about it. That problem comes from open source. The problem is, that it is > difficult to track these down, and to convince them to share their work as > contribution - another problem is that in such cases, the customizations > are often really custom, and not suitable for general distribution. > > Unrelated idea: there might be languagetool customizations that are freely > available, for example, github returns about 50 repositories to the > languagetool keyword ( > https://github.com/search?p=2&q=languagetool&type=Repositories&utf8=%E2%9C%93). > Some of these might be worthy to be included in the main repository. > > Regards, > Robert > > >> These are the options I can think of that go beyond "let's just keep >> going". Yes, we could just keep going - for some languages, LT is in good >> health. But to be a sustainable project in the long term, I think we need >> either more than one contributor per language or we need a technological >> approach that works without a maintainer per language. >> >> Please, everybody, let me know what you think and what ideas you have >> about the future of LanguageTool. >> >> Regards >> Daniel >> >> >> ------------------------------------------------------------------------------ >> Go from Idea to Many App Stores Faster with Intel(R) XDK >> Give your users amazing mobile app experiences with Intel(R) XDK. >> Use one codebase in this all-in-one HTML5 development environment. >> Design, debug & build mobile apps & 2D/3D high-impact games for multiple >> OSs. >> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 >> _______________________________________________ >> Languagetool-devel mailing list >> Languagetool-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/languagetool-devel >> >> >
------------------------------------------------------------------------------
_______________________________________________ Languagetool-devel mailing list Languagetool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/languagetool-devel
