Google's product managers for community projects

[George Moschovitis]

I hope most of us will agree on the following:

1. The Dart team is spread thin, we, as a community should help.

2. Compared to e.g. JavaScript, many lower-level libraries are still missing.

3. One of the selling points of Dart is the collection of homogeneous, harmonized libraries.

I am wondering if we could kill 2 birds (#1, #2) with one stone, while staying true to #3.

Idea: Product managers from the Dart team could overlook community packages to ensure high quality

and consistency with libraries released by the Dart team. 

For example, while I don't have much time to work on

a big project, I could find time to work on a lower-level package like data-structures (graph, ring/circular buffers, etc)

a statistics package, etc. If I could have the guidance of a product manager from Google to make sure the API is

consistent, feels Dartish, and is broadly reusable (thus discouraging others to spend time duplicating the same functionality 

as different packages), that would be a definite win for the community, IMO.

 

Is something like this practical?

[Jim Trainor]

Quality is a big issues.  I don't touch most of pub because, first, discoverability is weak and, second, even if I do find something quality is big unknown unless it's from google in which case I'm confident. I suspect there is a lot of stuff in pub already and that some curating would help. Ideally automated community driven curating - e.g. some sort of use indicator based on download information.

On Sat, May 23, 2015 at 4:55 AM, George Moschovitis <george.mo...@gmail.com> wrote:

I hope most of us will agree on the following:

1. The Dart team is spread thin, we, as a community should help.

2. Compared to e.g. Javascript, many lower-level libraries are still missing.

3. One of the selling points of Dart is the collection of homogeneous, harmonized libraries.

I am wondering if we could kill 2 birds (#1, #2) with one stone, while staying true to #3.

Idea: Product managers from the Dart team could overlook community packages to ensure high quality

and consistency with libraries released by the Dart team. 

For example, while I don't have much time to work on

a big project, I could find time to work on a lower-level package like data-structures (graph, ring/circular buffers, etc)

a statistics package, etc. If I could have the guidance of a product manager from Google to make sure the API is

consistent, feels Dartish, and is broadly reusable (thus discouraging others to spend time duplicating the same functionality 

as different packages), that would be a definite win for the community, IMO.

 

Is something like this practical?

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Jan Mostert]

My thoughts ...

Something which I've been toying with over the last week is dQuery, it's not feature complete, but looks like a very close replica of jQuery.

See: https://github.com/rikulo/dquery/blob/master/doc/Comparison.md

There's a gazillion jQuery widgets out there, if you could take any jQuery widget's javascript code, copy the jQuery and compile it with dart, you could effectively re-use all of that. If it was feature complete, people might actually use it more.

Bootjack is from the same developer, a close replica of Twitter Bootstrap in dart. I actually took Bootstrap's less files (from their source download), deleted the javascript and only imported Bootjack's dart code and instead of 1.5MB bloated app (which you often get if you import jQuery, bootstrap, all the css, a js file for each component, etc), I have a Twitter Bootstrap app with a couple of components that only loads 400kB at startup. Bootjack is not feature complete and looking at the github repo, it hasn't received much love in the last year.

Less Dart, a package that compiles less files and hooking perfectly into the pub serve / pub build process.

All three of these are high-quality packages, but are not well maintained because they are owned by one developer and not getting that well known compared to the let's say html package.

With a curator program, these packages can be moved into the dart eco-system, at first as experimental, but once they are sitting on github under the Google Dart account, more people would be willing to contribute on them.

On Sat, 23 May 2015 at 10:55 George Moschovitis <george.mo...@gmail.com> wrote:

I hope most of us will agree on the following:

1. The Dart team is spread thin, we, as a community should help.

2. Compared to e.g. Javascript, many lower-level libraries are still missing.

3. One of the selling points of Dart is the collection of homogeneous, harmonized libraries.

I am wondering if we could kill 2 birds (#1, #2) with one stone, while staying true to #3.

Idea: Product managers from the Dart team could overlook community packages to ensure high quality

and consistency with libraries released by the Dart team. 

For example, while I don't have much time to work on

a big project, I could find time to work on a lower-level package like data-structures (graph, ring/circular buffers, etc)

a statistics package, etc. If I could have the guidance of a product manager from Google to make sure the API is

consistent, feels Dartish, and is broadly reusable (thus discouraging others to spend time duplicating the same functionality 

as different packages), that would be a definite win for the community, IMO.

 

Is something like this practical?

[Günter Zöchbauer]

I'm not against this idea, but reviewing is a lot of work and then the reviewer might be hold responsible if he approves but there are still issues. I wouldn't want to be involved in such a process. 

Quality also is the responsibility of the community. What I think is missing, is a way to show how many people use a package and some way to rate packages (currently the stars at Github are the closest we get). 

If many people use a package and it receives good rating, it is a good indication the package is usable. 

I assume such statistics and rating for pub.dartlang.org could be added by the community with pull requests.

But rating also has a disadvantage. Early birds get a big advantage and it's hard for newer packages to gain traction even when they are better than the old ones. This might be a reason it's not added to pub.dartlang.org yet.

Improving the situation also involves taking a bit of risk and trying out packages to be able to give proper feedback about the quality, or fix issues yourself and provide pull requests if the package isn't yet as good as you want it or at least report the issues.
To complain that the overall quality of the packages is poor, doesn't help at all.

Most OS projects are things devs built for themselves and publish it to the advantage of others for whatever reason. The first step isn't free of issues most of the time. The more a package is used and the more issues are reported and fixed the better the package becomes.

If you want better packages, get involved.

[Joao Pedrosa]

Hi,

Since the Dart repositories started moving to GitHub there is a growing number of projects that willing community members can contribute to that will necessarily be supervised by Googlers.

What people would be most happy with would be if there were too many open source Dart projects going on. Quality would then "trickle down." But being too popular hasn't been one of Dart's issues, unfortunately. :-)

I guess what people needed to contribute more to Dart would be more hooks into extending the VM to their needs. Yesterday I read about a project in Haskell that allowed for extending Haskell [1] by calling directly into a numeric C library with the help of abstracted FFI. Sort of like what we can do with Fletch [2] by extending it with FFI. In LuaJIT [3] they also have extended it with FFI.

Something that I think Dart needed since it is so close to it would be to allow for a PHP style of templating. Take some program code, run it in an isolate, and then either cache it for further reuse or throw it away so that the memory can be freed. I mean that as a way of extending the Dart VM uses. Maybe somebody can do that already and we just don't know about it.

The downside to extending the VM in our own is that code may become more platform dependent then. So I understand the appeal to authority to keep things neat.

Cheers,

Joao

[1] - https://www.fpcomplete.com/blog/2015/05/inline-c

[2] - https://github.com/dart-lang/fletch/blob/master/tests/ffi/ffi_timeofday_test.dart

[3] - https://github.com/kernelsauce/turbo

[Jan Mostert]

There's this one package I love using, but it's been 18 months since any fixes were made to it and bug reports / feature requests are just hanging on github.

I can now go and fork this project, make the fixes and voila, there would be two pub packages, doing exactly the same thing.

6 months down the line, a better package comes out or the client suddenly decides to scrap the project I've been using this package in and there would be very little reason to keep on maintaining it and we suddenly have two unmaintained versions of the same project.

What is the general guideline for dart packages? Do I fork, fix and send a merge request hoping it gets merged back in or is there some way to completely take over an existing repo? Or is it possible to somehow share pub names, example I build a foobar package that can do ABC and somebody else also builds a foobar package that can do CDE. Now instead of having two complete different packages, there's one foobar package, you just supply details of which implementation you want to use (eg ABC). The same could probably be achieved by tags in pub, if two people tag their packages foobar, then anyone looking for foobar can just look at the foobar tag and see what is available for foobar.

[George Moschovitis]

The same could probably be achieved by tags in pub, if two people tag their packages foobar, then anyone looking for foobar can just look at the foobar tag and see what is available for foobar.

what about scoped package names in pub?

http://blog.npmjs.org/post/116936804365/solving-npms-hard-problem-naming-packages

 

[Kévin Platel]

I shared the idea about the actual issue of dart to promote or highlight good package with some quality insurance,
In this aspect, i like the initiative here : https://github.com/yissachar/awesome-dart 

And it would be very nice to offer a more advance features pub website with maybe the possibility to "star" a pub project, or propose a discover by category (as shown in the github repository), shown the most download package (as https://www.npmjs.com/) all this factor can be use to choose a package.

A package with a lot of download (so use by a lot a people) and with a lot a star (can be liked with the github star) will inspired me more.

--

[Jan Mostert]

If a rating system is put in place, at least have some weights in place, take into account total number of downloads, unresolved bugs, open issues that has not been given attention to, etc.

Therefore, if you define a quality package as a package where all reported issues gets addressed quickly, gets resolved in reasonable amount of time and how quickly those features are rolled out and on top of that downloads, then if developers vote on packages, you can calculate how much each of these parameters should weigh in an auto-grading system which should give you the ability to grade less known packages based on how other packages are performing.

So you could have two grades on a package, user-voted grade and system calculated grade, the two are then combined to give a final grade.

I'm assuming pub packages are not automatically linked with a specific github repo?

@George, NPN's scoping looks interesting! Could also be useful for the scenario where I fork a package that I need fixed now, switch scope to my own package and a week later once the maintainer has merged the pull request, I can switch back to his scope.

[Günter Zöchbauer]

I doubt you can get any useful information from issues. Not all packages are on Github. Not all packages are linked to Github. There is no reliable way to find out if an issue is a feature requests or a bug report and if the issues is valid at all. If you have a package which attracts a lot of beginner you get a lot of low-quality issues but that's not necessarily the fault of your package. I won't say there are no issues with stars though.  

[Celerity Abbottt]

This is a very good idea. It will for sure needs Dart / Google's involvement.

A few things that may be done:

- Curating packages and/or rating them are great ideas. One step further would be to take a page from Apache Software Foundation's playbook to incubate and promote promising Dart projects and packages, with quality criteria and guided processes. (See the success rate of Apache projects. )

- Google should value the work done and time spent by its Dart team members on building Dart community and ecosystem. Not sure if Dart team or Google in general REALLY value this kind of work and activities by it's members. (Other companies have dedicated engineers and 'evangelists" on these things -- that's their full time job.) As Dart is in Google's auspices, only can Google cultivate and reinforce quality in Dart packages and projects, by itself and 3rd parties.

- Periodically promote top Dart packages and projects in blogs, conferences and shows. In Dart Submit 2015, not sure if any 3rd party Dart libraries were presented or highlighted. Hope there would be some in Dart Submit 2016 or other Google events.

Hope Dart team gets excited about this idea, and does something. Maybe it can find a few college Summer interns to get it started.

[Thomas Schranz]

I think we see some of that already happening organically (eg check out Devon's contributions to Atom related packages)

or browse through the commit logs of some popular community packages in general.

What I would love to see (maybe it already exists?) is an example & maybe article on what makes a good package

to raise the status quo (make it easy) similar to directory layout conventions.

From the top of my mind:

* have tests & build badges

* add travis ci/drone/codeship etc (how-to, recommended platform? …)

* recommended structure of readme files (not only highlighting readmes but go further + examples)

* screenshots

* example code in /examples and also in readme

* changelog

this obviously is just tangential to code quality but it is the initial ux when someone tries to figure out if

a package might be a good fit for what they are trying to do.

i think some communities have done a better job here than others @ defining what is expected and how things are laid out.

eg (also from top of my mind and might not be super accurate):

ruby == good testing culture, bad documentation culture

python == great documentation culture

npm/js == strong branding & product-like website culture

imho worth to define what we care about and what we regard as a great package ux and then

take that a s a checklist to help packages improve here (PRs etc).

[Bob Nystrom]

On Sat, May 23, 2015 at 6:07 AM, Jan Mostert <jan.m...@gmail.com> wrote:

There's this one package I love using, but it's been 18 months since any fixes were made to it and bug reports / feature requests are just hanging on github.

I can now go and fork this project, make the fixes and voila, there would be two pub packages, doing exactly the same thing.

6 months down the line, a better package comes out or the client suddenly decides to scrap the project I've been using this package in and there would be very little reason to keep on maintaining it and we suddenly have two unmaintained versions of the same project.

What is the general guideline for dart packages? Do I fork, fix and send a merge request hoping it gets merged back in or is there some way to completely take over an existing repo?

This isn't specific to Dart but I think the typical way to do this in open source is to try to contribute first and only fork or take over if necessary. If the original author has given up on it, they may be willing to just pass the torch to you, which avoids the pain of forking.

 

Or is it possible to somehow share pub names, example I build a foobar package that can do ABC and somebody else also builds a foobar package that can do CDE. Now instead of having two complete different packages, there's one foobar package, you just supply details of which implementation you want to use (eg ABC).

For all intents and purposes a package that does ABC and a package that does ABCDE are different packages, so it makes sense to me for them to have different names. In some cases, you can make a package that just does DE and relies on the original package to do ABC.

But, overall, I think it's clearer to users if the packages have their own names even if they have the same progeny. Once you've forked, the packages will tend to diverge over time, so giving them their own name and identity is probably a good move. You can always document that whizbang was a fork of foobar.

 

The same could probably be achieved by tags in pub, if two people tag their packages foobar, then anyone looking for foobar can just look at the foobar tag and see what is available for foobar.

Even just better search on pub.dartlang.org that included the package's README would go a long way here.

- bob

[Bob Nystrom]

On Sat, May 23, 2015 at 7:50 AM, Jan Mostert <jan.m...@gmail.com> wrote:

If a rating system is put in place, at least have some weights in place, take into account total number of downloads, unresolved bugs, open issues that has not been given attention to, etc.

Therefore, if you define a quality package as a package where all reported issues gets addressed quickly, gets resolved in reasonable amount of time and how quickly those features are rolled out and on top of that downloads, then if developers vote on packages, you can calculate how much each of these parameters should weigh in an auto-grading system which should give you the ability to grade less known packages based on how other packages are performing.

So you could have two grades on a package, user-voted grade and system calculated grade, the two are then combined to give a final grade.

I've wanted to do this kind of stuff forever, but we just never had the time. Natalie and I—the ones who wrote the original pub.dartlang.org—are stretched really thin and server features never became much of a priority. The server has new owners now, so I'm hoping they'll have more time to get to features like this.

 

I'm assuming pub packages are not automatically linked with a specific github repo?

We don't do it automatically, but it would be easy to add a "repository" field to the pubspec so users can indicate the connection.

Cheers!

- bob