5 ms·

And while they move, they are filing issue bankruptcy. 574 open issues exist for TypeScript on Codeplex. https://typescript.codeplex.com/workitem/list/basic ht

by mixonic 12y ago

And while they move, they are filing issue bankruptcy. 574 open issues exist for TypeScript on Codeplex. https://typescript.codeplex.com/workitem/list/basic https://typescript.codeplex.com/workitem/list/basic "Please note: since we’re moving to a new issue tracker and a new codebase, we are not copying all issues over. If you have issues in the current CodePlex issue tracker, please try them against the new codebase and file them in the GitHub issue tracker if they still repro." Github is back up to 117. Managing an open source community is something that the TypeScript leadership still have yet to learn. They weren't concerned about coordinating with TC39 on module syntax (they shipped 1.0 with an arbitrary snapshot), they were never very interested in accepting code, and they don't value the time users take to document bugs and edge cases. tl;dr the move to Github is lipstick on a pig. It is a distraction from the real changes they must make on order to collaborate well with others.

skybrian 12y ago
Many high-profile open source projects have far more bug reports than they know what to do with. Declaring issue bankruptcy and asking people to re-test with a new version is annoying from a customer service point of view, but looked at another way, it's a scalable way for the community to help. Cut and paste (or better yet, summarize the conversation) isn't so hard if it's still a real issue.
- frowaway001 12y ago
  Or ... TypeScript developers could just have added test cases to their test suite and figure out automatically whether the new implementation fixed things or caused regressions.
  - hvs 12y ago
    "just adding test cases" is not a free act. It requires work on the developers part.
    - frowaway001 12y ago
      Sure. It's just the decision between " our bug reporters and all the time and work they spent" vs. "let's go through the issue database and migrate tickets which look useful. I mean, really? Less than 600 bugs, and they couldn't be bothered? Even with a small team. this could have been done in a day. And it's not like it would be extra work, because going through the bug tracker and trying to get a broader view of the issues raised should be a thing which happens continually anyway.
  - thornkin 12y ago
    That doesn't help if (as stated above) there are a lot of duplicate issues. You still have to figure out which test case applies to each report.
aikah 12y ago
> (they shipped 1.0 with an arbitrary snapshot) They will have no choice but to change the Typescript module system,or it will stop being compatible for Ecmascript. Right now afaik Typescript doesnt support generators either. It's a great language but the way they handled module in Typescript was a mistake.
- frowaway001 12y ago
  Is there still no support for let and const? I think that's the most embarrassing thing about TypeScript.
- kevingadd 12y ago
  The only alternative they really had would be to not align with ES6/ES7 at all. The 6/7 specs are still in total flux and there are still intricate arguments/discussions on the spec list on a regular basis about the details of modules, module loaders, imports...
Arnavion 12y ago
>574 open issues exist for TypeScript on Codeplex. https://typescript.codeplex.com/workitem/list/basic https://typescript.codeplex.com/workitem/list/basic A lot are duplicates. There are two or three issues for type unions, atleast two issues for ABCs, and so on. Also a some of the issues are for VS integration. >Github is back up to 117. I only glanced at the GH issues but it seems they're actually internal issues discovered by the devs themselves, not from the Codeplex tracker.
MichaelGG 12y ago
Especially compared to the F# compiler, which is actively accepting pull requests and even indicating which issues they'd like people to take up.
greggman 12y ago
all of that seems true for most repos on github. At least in my experience. I've spent the last 2 months learning node, checking out npm modules, finding bugs, seeing the projects abandoned, lots of issue filed, pull requests ignored, etc.. Maybe I've just been unlucky but this hardly seems like an MS specific thing?
- Pacabel 12y ago
  I think this is partially due to the informality that many GitHub users tend to have with respect to managing their projects. It's rare to see a GitHub-hosted project that offers proper releases, proper planning for those releases, proper documentation, and the organization and project management efforts that enable such things. The lack of such basic project management structure leads to projects that see very erratic development, or outright abandonment. Many GitHub-hosted projects are barely more than a hobby, rather than an ongoing concern. Their code may be somewhat usable, but it's rarely comparable to what we see from more organized projects.
  - snogglethorpe 12y ago
    I don't see that as a bad thing. Mostly it seems to be a reflection of how low the barrier to entry is on github. It's easy to get up and running there, so naturally lots of people do, even if it's just a hobby project they work on once a year during Christmas break....
  - watwut 12y ago
    Proper release planning for tiny one man fifteen users project is very little planing. Those projects do not get erratic development or get abandoned because they lack "proper planing". That is reversing cause and effect. They lack heavy planing because their development depends too much on free time of one or two people, who have other life priorities. No amount of planning will change that.
- lumpypua 12y ago
  Easy packaging and distribution is awesome and it's why node's ecosystem has exploded, but tools to filter that down are equally important. A great example of this is djangopackages.com. Looking at thumbnailing packages[2] even though there are a dozen packages, only three are popular. And taking a glance at the commit sparklines only two are under active development. So I know to start with them. [2] https://www.djangopackages.com/grids/g/thumbnails/ https://www.djangopackages.com/grids/g/thumbnails/
coldtea 12y ago
>Managing an open source community is something that the TypeScript leadership still have yet to learn. It's not like Gnome/GTK and KDE managed such issues so much better...
nailer 12y ago
Does TC39 interact with the community on module syntax? AFAK everyone in node land has no intention of using ES6 modules.
- mixonic 12y ago
  If people in "node land" want to keep using JavaScript they will eventually be using ES6 modules. Or they will fork the language. I would not place money on the Node team wanting to fork JavaScript.
  - nailer 12y ago
    For real? Existing JS module systems are just closures, they won't stop working in ES6

by mixonic 12y ago

skybrian 12y ago

Many high-profile open source projects have far more bug reports than they know what to do with. Declaring issue bankruptcy and asking people to re-test with a new version is annoying from a customer service point of view, but looked at another way, it's a scalable way for the community to help. Cut and paste (or better yet, summarize the conversation) isn't so hard if it's still a real issue.

frowaway001 12y ago
Or ... TypeScript developers could just have added test cases to their test suite and figure out automatically whether the new implementation fixed things or caused regressions.
- hvs 12y ago
  "just adding test cases" is not a free act. It requires work on the developers part.
  - frowaway001 12y ago
    Sure. It's just the decision between " our bug reporters and all the time and work they spent" vs. "let's go through the issue database and migrate tickets which look useful. I mean, really? Less than 600 bugs, and they couldn't be bothered? Even with a small team. this could have been done in a day. And it's not like it would be extra work, because going through the bug tracker and trying to get a broader view of the issues raised should be a thing which happens continually anyway.
- thornkin 12y ago
  That doesn't help if (as stated above) there are a lot of duplicate issues. You still have to figure out which test case applies to each report.

aikah 12y ago

> (they shipped 1.0 with an arbitrary snapshot) They will have no choice but to change the Typescript module system,or it will stop being compatible for Ecmascript. Right now afaik Typescript doesnt support generators either. It's a great language but the way they handled module in Typescript was a mistake.

frowaway001 12y ago
Is there still no support for let and const? I think that's the most embarrassing thing about TypeScript.
kevingadd 12y ago
The only alternative they really had would be to not align with ES6/ES7 at all. The 6/7 specs are still in total flux and there are still intricate arguments/discussions on the spec list on a regular basis about the details of modules, module loaders, imports...

Arnavion 12y ago

>574 open issues exist for TypeScript on Codeplex. https://typescript.codeplex.com/workitem/list/basic https://typescript.codeplex.com/workitem/list/basic A lot are duplicates. There are two or three issues for type unions, atleast two issues for ABCs, and so on. Also a some of the issues are for VS integration. >Github is back up to 117. I only glanced at the GH issues but it seems they're actually internal issues discovered by the devs themselves, not from the Codeplex tracker.

MichaelGG 12y ago

Especially compared to the F# compiler, which is actively accepting pull requests and even indicating which issues they'd like people to take up.

greggman 12y ago

all of that seems true for most repos on github. At least in my experience. I've spent the last 2 months learning node, checking out npm modules, finding bugs, seeing the projects abandoned, lots of issue filed, pull requests ignored, etc.. Maybe I've just been unlucky but this hardly seems like an MS specific thing?

Pacabel 12y ago
I think this is partially due to the informality that many GitHub users tend to have with respect to managing their projects. It's rare to see a GitHub-hosted project that offers proper releases, proper planning for those releases, proper documentation, and the organization and project management efforts that enable such things. The lack of such basic project management structure leads to projects that see very erratic development, or outright abandonment. Many GitHub-hosted projects are barely more than a hobby, rather than an ongoing concern. Their code may be somewhat usable, but it's rarely comparable to what we see from more organized projects.
- snogglethorpe 12y ago
  I don't see that as a bad thing. Mostly it seems to be a reflection of how low the barrier to entry is on github. It's easy to get up and running there, so naturally lots of people do, even if it's just a hobby project they work on once a year during Christmas break....
- watwut 12y ago
  Proper release planning for tiny one man fifteen users project is very little planing. Those projects do not get erratic development or get abandoned because they lack "proper planing". That is reversing cause and effect. They lack heavy planing because their development depends too much on free time of one or two people, who have other life priorities. No amount of planning will change that.
lumpypua 12y ago
Easy packaging and distribution is awesome and it's why node's ecosystem has exploded, but tools to filter that down are equally important. A great example of this is djangopackages.com. Looking at thumbnailing packages[2] even though there are a dozen packages, only three are popular. And taking a glance at the commit sparklines only two are under active development. So I know to start with them. [2] https://www.djangopackages.com/grids/g/thumbnails/ https://www.djangopackages.com/grids/g/thumbnails/

coldtea 12y ago

>Managing an open source community is something that the TypeScript leadership still have yet to learn. It's not like Gnome/GTK and KDE managed such issues so much better...

nailer 12y ago

Does TC39 interact with the community on module syntax? AFAK everyone in node land has no intention of using ES6 modules.

mixonic 12y ago
If people in "node land" want to keep using JavaScript they will eventually be using ES6 modules. Or they will fork the language. I would not place money on the Node team wanting to fork JavaScript.
- nailer 12y ago
  For real? Existing JS module systems are just closures, they won't stop working in ES6