Really pleased to see the input from you all, and thanks for the revisions
and corrections so far.
"To me it's a bit difficult to digest in its current format. I would prefer
to
see a list of design patterns with descriptions of concrete problems and
proposed solutions."
I definitely agree. I had already considered splitting it into two docs :
definitions and implementation guide, but it was mostly 'notes' to begin
with so I just kept them all in the one doc. I think we should split it out
like that once we agree that the definitions are solid, then we can focus
on the implementation guide, populating it with content from discussions
that have already begun, and then adding more in the future in exactly the
way ( PAYG-ish ) that you describe.
"I'm just not sure we are ready to start paving roads and putting up street
signs."
If by this you mean end-user documentation, then I had only suggested that
it would be easier to get there flowing on from things like this. This
effort is simply about being cohesive for the overall direction we are
supposed to be heading together as a project. If we can't describe
fundamental things in a way we all understand and agree with then it can
make it difficult to collaborate in order to proceed together in the same
direction. That's more about general project management than it is to do
with anything else, in my experience. What I had suggested (or had intended
to convey) was that this type of documentation would also make it easier to
create other more user-focused content for 1.0 and beyond as well, but that
is not the main reason for this now.
" We also DESPERATELY need better documentation and guides. Unfortunately
most of us are not great writers. :-("
I'm assume none of us actually 'likes' writing documentation (I certainly
don't!). But we (a few of us at least) can't say we don't actually have
time to write documentation, because we do have time to write (sometimes
very long, like this one) discussion posts. All we need is a discussion
topic that is focused on the output of a specific piece of content
(document topic heading) and we can all work on it together 'while not
really writing documentation' :). And all we need as a starting point for
that is a skeletal document outline. The idea here is not to do more work,
or even to do things we don't 'like' but to use an activity we already
actually do to in what I think is a more productive way. If we can get this
to work once for PAYG, maybe we can keep it rolling with new topic areas.
Can we please start a new discussion for definition of the component sets
and respective goals (and the degree of relevance or irrelevance to PAYG as
a concept), and keep this thread for general content
(corrections/omissions etc)
I will start another thread on beads before too long and bring in as much
of the historical content from previous discussions in as a starting point.
This would be for the 'implementation guide' part.
Thanks to Harbs and Alex for already editing the doc.
I will harvest any additional content I can get from this thread into the
wiki doc and also other topic threads suggested above if that is what
people prefer. And I will split the wiki doc out to definitions and
implementation guide as separate pages this coming weekend, as per Yishay's
request.
I'm going to stop there!
On Tue, Jul 4, 2017 at 12:03 PM, Justin Mclean <jus...@classsoftware.com>
wrote:
> Hi,
>
> > You could be right that folks are just too used to the old Flex way of
> > thinking. If you've never hit the performance and size issues I've seen
> > then maybe you can't understand the motivation behind it, but that might
> > mean the active committers are self-selected.
>
> I’ve worked on many large enterprise Flex systems and while we run into
> performance issues from time to time but they were generally solvable.
> Sometimes in the code itself or at worse by monkey patching the SDK. Not
> everyone experience is going to be the same.
>
> > it could be that the big enterprises that have been
> > burned by old Flex's size and performance are no longer active Flex
> > customers.
>
> There are a large number of reasons for that i.e a lot of big enterprises
> like paid support from a supplier, some are still reluctant to using open
> source (although that is changing) and finding Flex developers these days
> is hard and/or expensive, other frameworks may have more traction,
> popularity, hype or larger communities behind them.
>
> > Documentation is always a good thing, but as I've said several times,
> this
> > is bleeding-edge development.
>
> Having worked on a number of bleeding-edge systems IMO I’m not sure it
> really qualifies for the term. There are other frameworks in this space,
> other cross compilers etc etc and there’s nothing really that cutting edge
> about it. It’s true that it’s currently mostly untested in production so in
> that way it may qualify.
>
> > I'm just not sure we are ready to start paving roads and putting up
> street signs.
>
> If we want to attract other developers / committers it may be a good idea
> to at least leave some notes on the direction travelled and how to get
> there.
>
> > Adobe can pull me off at any time.
>
> All the more reason IMO to have some documentation and censuses around
> concepts like PAYG. Bus factor is a concern here. [1]
>
> > My managers would much rather that I help one or two customers migrate
> their code than
> > write documents so 100 folks can migrate on their own because we still
> > have enough bugs and missing features that the 100 would have little
> > chance of being successful
>
> Those's 100 people would get help from the mailing list and would
> hopefully become committers themselves. I think you may be thinking that
> Flex needs more full time people sponsored by a corporation working on it.
> That would be nice but also don’t discount part time committers working on
> it as well as there’s room for both.
>
> > And having a successful customer improves the chances that Adobe will
> continue to pay me to work on FlexJS.
>
> What do you (or Adobe) define as successful here? We're currently working
> on an application what does it need to do to help that?
>
> Thanks,
> Justin
>
> 1. https://en.wikipedia.org/wiki/Bus_factor
