Setting expectations for community involvement

Topics: General
Jan 3, 2013 at 6:51 PM

I'm guessing you guys must be using a different system for tracking your work items - other than codeplex - because I see only five items assigned to the (presumably) impending 0.8.2 release - of which one is active, one is closed, and three are proposed. Since I suspect that more work has gone into 0.8.2 than this, I'm concluding that you must be using an internal MS system for tracking your work items. I imagine that you have your reasons for doing this, but it does of course limit community participation, and decreases community visibility into what's coming. Have you given any thoughts to moving *everything* public?

I also haven't seen any accepted pull requests (three have been declined, the others are "being evaluated"). Are you planning to accept contributions from the community? What sort of expectations should folks have along those lines?

Also, have you given any thoughts to open-sourcing the Visual Studio add-in?

Coordinator
Jan 4, 2013 at 4:55 PM

Indeed, we do use both an public and a private issue tracker.  While we can't move everything public, as some of the issues may pertain to internal projects/security issues, we're looking at ways to make more of it public.  It's helpful for the community to be able to see and give feedback more easily, and it's also just less overhead on the team to manage two different trackers.

We're also looking to make our design discussions and notes public so that it's easier for the community to jump in.  It's largely a historical why we're a little quiet, and we're moving to being more transparent so that we can work with everyone else more closely.

When we went public, we knew that we were going to be previewing the technology and that it was some of the processes behind the scenes wouldn't be quite ready.  Pull requests is another one we knew wasn't going to be quite ready, but we started actively working towards them.  Microsoft is very careful about the intellectual property rights of others, and there were a few steps we needed to take on our side to keep things to a high bar before jumping in and accepting patches. 

Lastly, we'll likely not open source the VS add-in.  The VS add-in isn't actually all that interesting, as almost all of the smarts are in the language service (minus the debugging support, which is internal).  The language service is open source and you can get it from the source repo. 

Jan 4, 2013 at 6:33 PM

Good to hear, Jon. I think TypeScript is a great idea, and I'm looking forward to using and supporting it as much as I can. I'm about 5000 lines into my first major project with it, and while it has major rough edges (generics! generics! generics!), it's made my life much easier than if I had to deal with raw JavaScript all day long.

Jan 7, 2013 at 9:27 PM

Jon - any chance you can drop a hint of any upcoming releases?

Would be nice to get another build even if it has only a feature or two :)

I'm living in TypeScript lately so any extra goodies would be huge for me!

Coordinator
Jan 9, 2013 at 6:08 PM

JonKragh,

Definitely.  We're due to put up a blog post very soon about what's coming next, so keep an eye out for that.

Jan 11, 2013 at 2:06 PM

Awesome!

Between TypeScript, my hacked together code generator to bring my C# Poco typedefs to typescript, and knockoutjs....I'm loving this programming model!

Jan 11, 2013 at 6:22 PM

@JonKragh,

A code generator for transforming C# POCO to TypeScript sounds interesting.

Would you care to elaborate or share some insights?

Thanks.

Noel

Jan 11, 2013 at 7:09 PM

Sure - check this thread: http://typescript.codeplex.com/discussions/406685

It was a proof of concept at that point which I now use.  I've extended it to code gen knockout view models and handle more types since that point.

I think the good parts are: code gen template is a razor view & very simple to extend.  If there's interest I can throw up my latest template.

It works great.  I have strongly typed knockout viewmodels and also our core entities (e.g. request/response message structures, error structures, etc) and our domain entities on the client! Objects that we worked years on refining....