On 9/7/16, 7:48 AM, "Justin M. Hill" <jus...@prominic.net> wrote:
> > >Hi Alex, > >On the topic of a roadmap to FlexJS 1.0 -- > >I agree about needing a real-world application to consider FlexJS 1.0 >being >a good point of reference, but I think we might be in a bit of a catch-22 >situation. > >If we call it 1.0, more people will give it a try. Even internally at >Prominic, people have at first been hesitant to think we could get >anywhere >with FlexJS because it is not "1.0" yet. So there is something >psychological about that number to the world of software. On the one >hand, we don't want to just randomly call it 1.0, but we need to figure >out >what minimum remaining features the group needs to get their own projects >working on it as a 1.0 probably. After all, I suspect most people pouring >resources into FlexJS are doing so as a means to breath life into their >existing Flex software investments. I agree. I am usually conservative (maybe too much so) about setting expectations and exceeding them instead of the opposite, which is why I am looking for success stories. It is interesting to see a new name popup on the mailing lists with a FlexJS question, so it makes me wonder where folks are in their evaluation/development process. > >So my question is: what does the rest of the group need to call it 1.0? >At Prominic, Bootstrap integration and data binding have been two notable >holdups. Prominic team, please speak up on what else we need. > >I suggest on the "FlexJS - roadmap to 1.0 release" thread we ask everyone >who is active right now to submit on JIRA what their personal goal for a >1.0 release over the next 2 weeks. We need to get the group in the habit >of using JIRA to stay organized so priorities don't get buried in these >e-mail threads in my opinion. > >Some people like us don't have JIRA rights AFAIK so maybe we can also ask >people to post JIRA addition requests in a specific way to the list so >someone else who does have rights can post them. Like a subject of "JIRA >addition for 1.0 target:" You mean, you can't comment on JIRA issues? We should be able to allow that. Spin off another thread with specifics. We currently only let committers assign and close bugs, but if Dhwani and others contribute more code to the framework they could be elected as committers. > >After the 2 week time-frame of submissions, the group can then choose a >method to organize the JIRA tickets into those that actually the group >decides should be 1.0 vs. those that could wait until 1.1 release. So one interesting thing about Apache projects is that "organizing" and "roadmaps" and "priorities" aren't binding. Because everyone here is a volunteer and many have other priorities in their $dayjob, Apache projects cannot hold anyone accountable for getting anything done, and thus having roadmaps and backlogs are often frowned upon since they have no actual power. Instead, contributions to Apache projects is supposed to be a bit more like a potluck. There can be loose agreement on what is important and who is bringing salad vs a main dish, but people can generally work on what is important to them, and nobody is supposed to say "why are you working on that, it isn't the top priority?" This is good in many ways, because I'll bet anything being worked on for FlexJS these days is important to the person working on it. And by skipping the whole discussion of how important it is in the bigger picture, they can just get it done and inch us closer to that testimonial. That's why I'm looking forward to Peter taking on writing our website's Team Page in FlexJS. It will make us eat our own dog food and help us see what is missing. What it doesn't buy you is predictability of when we'll get that testimonial. For sure, collecting tasks/bugs/features in JIRA is a good thing, so yes, folks should fill up JIRA with what they need even just to avoid two people working on the same thing. However, I'm not sure we can have a cut-off and make 1.0 vs 1.1 buckets. We don't want to discourage newcomers by saying "no, your wish isn't important enough". We want to ask them to help us help themselves by trying to code up their wish themselves and thus grow the number of people pushing us forward. We have at least one company who has gambled on getting a FlexJS app into production. I am hopeful there are more we don't know about. If you can find one project at Prominic and gamble on it, you might become the providers of that testimonial yourself. Can you rewrite your website in FlexJS? Do you want to create your learning content with FlexJS? Do you want to start on a Tour de FlexJS? The latter, if you contribute it to Apache, would be a fast way to get your developers on the track to become committers. And once you get committers on your team, you have way more control. If you need a bug fixed, your folks can do it instead of waiting for someone to do it. > >Regarding the competitive analysis of FlexJS to tools like Xamarin, >Prominic can try to write something, but we really could use feedback >(off-list is fine if it is against policy) from others more knowledgeable >than us. I really think this is important so new people can have the >information handed to them about why this is useful. I guess non-profits aren't allowed to "compete", so project members have to be careful when making comparisons. I'm not sure why you are worried about Xamarin. I think there are plenty of other choices for folks like Angular 2 and React. Not to mention Dart and TypeScript. AIUI, folks can share their thoughts publicly on this list, but the project itself has to be careful about publishing anything comparative that isn't a fact. IOW, you could post how fast or how big running the same source through project A is vs FlexJS. Or say that our Hello World is bigger or smaller. But the project's web and wiki pages can't talk about how ActionScript is better than TypeScript because "better" or FlexJS is better than XXX because is just too subjective. A list of features might be ok if it is truly factual. HTH, -Alex
