Re: gitter

[Mark Waddingham via use-livecode]

Indeed our split isn't perfect - so there's a list of things we can and cannot 
do - depending on which engine version is needed to support the changes - this 
forces a good process (because it forces thought on it).

The submodule link is a version dependence - it's just hard to think of it like 
that because we go engine->ide, rather than ide->engine which would be 'better'.

Of course I use the term A/B testing - but that's just a superset of what we 
are already doing (we're just doing one test at a time at the moment and 
probably will do for quite a while).

However, the underlying process should be the same - and the points of friction 
are actually also points of potential error (in terms of if the boundaries 
weren't there then it would be where we could be more likely to make a mistake) 
- so those points of friction help maintain good process (because it forces us 
to think about the dependencies).

A lot of the IDE first run things are just superficial in the sense they are 
entirely ide code, and engine tweaks are generally fixes which have to follow 
maintenance procedure anyway.

And yes, submodule a cause grumblings internally and from contributors - so 
that just requires tooling to help, and a gradual cleanup of the boundaries of 
our repos so we can eventually restructure slightly to serve us better until 
they aren't a problem anymore. Retaining our quality process is higher priority 
I think, and should come first right now - that's all.

Warmest Regards,

Mark.

Sent from my iPhone

> On 30 Jul 2017, at 23:17, Monte Goulding via use-livecode 
>  wrote:
> 
> 
>>> On 31 Jul 2017, at 6:59 am, Mark Wieder via use-livecode 
>>>  wrote:
>>> 
>>> 
>>> Actually, submodules actually do their job really quite well. They aren't 
>>> ideal, but they do enforce modularity (hence the name ;)). We just need to 
>>> get round to sorting out some tooling (local shell scripts / git hooks) to 
>>> help make sure they aren't quite so easy to forget about syncing properly.
>> 
>> It's possible (and IMO preferable) to have a modular approach to app 
>> building in makefiles and such without forcing git to have to deal with that.
> 
> Submodules are very helpful when they are doing what they are meant to do 
> which is point to a specific version of a dependency.
> 
> Unfortunately with the ide submodule we have two way dependencies and tests 
> that break in one or the other or both if they aren’t updated in sync. Indeed 
> we have some ide libraries in the engine repository. So sometimes to make a 
> seemingly small patch you need to patch both repos. Additionally it’s easy to 
> break an IDE test and not find out about it until everything is merged up 
> because tests are run against the main repo (this is potentially solvable by 
> working out how to run the tests for all the submodules but it will require 
> some special Travis wrangling). 
> 
> There is an overhead to all this that I personally believe doesn’t justify 
> the benefits. Should we have IDE A/B test versions then I think we will need 
> to branch the engine repo for them sometimes anyway so any benefits may be 
> less than they at first appear… indeed the scenario may multiply the 
> overheads… 
> 
> Anyway, probably better to continue this discussion internally as not may 
> people here would be interested in this.
> 
> Cheers
> 
> Monte
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Monte Goulding via use-livecode]

> On 31 Jul 2017, at 6:59 am, Mark Wieder via use-livecode 
>  wrote:
> 
>> 
>> Actually, submodules actually do their job really quite well. They aren't 
>> ideal, but they do enforce modularity (hence the name ;)). We just need to 
>> get round to sorting out some tooling (local shell scripts / git hooks) to 
>> help make sure they aren't quite so easy to forget about syncing properly.
> 
> It's possible (and IMO preferable) to have a modular approach to app building 
> in makefiles and such without forcing git to have to deal with that.

Submodules are very helpful when they are doing what they are meant to do which 
is point to a specific version of a dependency.

Unfortunately with the ide submodule we have two way dependencies and tests 
that break in one or the other or both if they aren’t updated in sync. Indeed 
we have some ide libraries in the engine repository. So sometimes to make a 
seemingly small patch you need to patch both repos. Additionally it’s easy to 
break an IDE test and not find out about it until everything is merged up 
because tests are run against the main repo (this is potentially solvable by 
working out how to run the tests for all the submodules but it will require 
some special Travis wrangling). 

There is an overhead to all this that I personally believe doesn’t justify the 
benefits. Should we have IDE A/B test versions then I think we will need to 
branch the engine repo for them sometimes anyway so any benefits may be less 
than they at first appear… indeed the scenario may multiply the overheads… 

Anyway, probably better to continue this discussion internally as not may 
people here would be interested in this.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Doing user testing in a risk free way (Re: gitter)

[hh via use-livecode]

> Monte wrote:
> I’m not really sure that A/B tests of the IDE is something we should be
> attempting to do at all as we don’t have the resources to do it with the
> number of people required to get decent data.

+42
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Doing user testing in a risk free way (Re: gitter)

[Monte Goulding via use-livecode]

> On 31 Jul 2017, at 6:56 am, J. Landman Gay via use-livecode 
>  wrote:
> 
> I'm just wondering, should I wait for the A/B test sequences or just throw a 
> current version at him?

Well there’s not much point doing A/B tests unless you have a decent size group 
to gather data on which performed better A or B. I would just get him to 
download (with no other instruction) from LiveCode and take a note which 
version & edition he ends up getting.

I’m not really sure that A/B tests of the IDE is something we should be 
attempting to do at all as we don’t have the resources to do it with the number 
of people required to get decent data. Observe and enhance on the other hand 
has been working well other than the version numbering which needs some 
attention.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Doing user testing in a risk free way (Re: gitter)

[Richmond Mathewson via use-livecode]

I don't believe there is anything that is "risk free".

HOWEVER, I am looking to set up programming classes throughout the year 
starting in October, at which point I should

have both:

1. Kids with NO programming experience whatsover.

2. Kids with experience in either Visual BASIC and/or C++.

Richmond.

On 7/30/17 11:56 pm, J. Landman Gay via use-livecode wrote:

On 7/30/17 3:32 PM, Monte Goulding via use-livecode wrote:


On 31 Jul 2017, at 5:09 am, J. Landman Gay via use-livecode 
 wrote:


Do you need test subjects or do you need to observe them directly? I 
have a neighbor who would be ideal. I was thinking I could watch him 
(with my mouth firmly shut) and take notes on what happens.


He's currently learning another language (javascript maybe, can't 
remember) so he is computer literate but has zero experience with LC.


Jacque I think I can speak for the team on this that if ever anyone 
wants to observe someone’s first run with LiveCode and create bug 
reports about issues they encountered or things we could add to make 
the experience flow better then go right ahead. You could do this 
with the version of LiveCode you think is best at the time.


I'm just wondering, should I wait for the A/B test sequences or just 
throw a current version at him?




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Mark Wieder via use-livecode]

On 07/29/2017 03:49 PM, Mark Waddingham via use-livecode wrote:

Actually, submodules actually do their job really quite well. They 
aren't ideal, but they do enforce modularity (hence the name ;)). We 
just need to get round to sorting out some tooling (local shell scripts 
/ git hooks) to help make sure they aren't quite so easy to forget about 
syncing properly.


It's possible (and IMO preferable) to have a modular approach to app 
building in makefiles and such without forcing git to have to deal with 
that.


--
 Mark Wieder
 ahsoftw...@gmail.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Doing user testing in a risk free way (Re: gitter)

[J. Landman Gay via use-livecode]

On 7/30/17 3:32 PM, Monte Goulding via use-livecode wrote:



On 31 Jul 2017, at 5:09 am, J. Landman Gay via use-livecode 
 wrote:

Do you need test subjects or do you need to observe them directly? I have a 
neighbor who would be ideal. I was thinking I could watch him (with my mouth 
firmly shut) and take notes on what happens.

He's currently learning another language (javascript maybe, can't remember) so 
he is computer literate but has zero experience with LC.


Jacque I think I can speak for the team on this that if ever anyone wants to 
observe someone’s first run with LiveCode and create bug reports about issues 
they encountered or things we could add to make the experience flow better then 
go right ahead. You could do this with the version of LiveCode you think is 
best at the time.


I'm just wondering, should I wait for the A/B test sequences or just 
throw a current version at him?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Mark Wieder via use-livecode]

On 07/29/2017 03:59 PM, Mark Waddingham via use-livecode wrote:

I have a thick skin, I can happily ignore such grumblings;


I'm not sure that's the proper response to the grumblings 

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Doing user testing in a risk free way (Re: gitter)

[Monte Goulding via use-livecode]

> On 31 Jul 2017, at 5:09 am, J. Landman Gay via use-livecode 
>  wrote:
> 
> Do you need test subjects or do you need to observe them directly? I have a 
> neighbor who would be ideal. I was thinking I could watch him (with my mouth 
> firmly shut) and take notes on what happens.
> 
> He's currently learning another language (javascript maybe, can't remember) 
> so he is computer literate but has zero experience with LC.

Jacque I think I can speak for the team on this that if ever anyone wants to 
observe someone’s first run with LiveCode and create bug reports about issues 
they encountered or things we could add to make the experience flow better then 
go right ahead. You could do this with the version of LiveCode you think is 
best at the time.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Doing user testing in a risk free way (Re: gitter)

[J. Landman Gay via use-livecode]

On 7/30/17 12:16 AM, Mark Waddingham via use-livecode wrote:

**How can all our existing users help with our user testing?

Well, the above approach has one further *really* useful aspect. For any 
licenses which are not marked with a test funnel (or indeed are marked 
with a dead test funnel) we can show a drop-down list in preferences for 
all currently available tests.


Choosing one would reboot the IDE into that test's IDE. The result? Any 
of you can play around with the things we are testing and give us 
feedback on them without it affecting your workflow or use of the IDE at 
all.


Do you need test subjects or do you need to observe them directly? I 
have a neighbor who would be ideal. I was thinking I could watch him 
(with my mouth firmly shut) and take notes on what happens.


He's currently learning another language (javascript maybe, can't 
remember) so he is computer literate but has zero experience with LC.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Doing user testing in a risk free way (Re: gitter)

[Mark Waddingham via use-livecode]

On 2017-07-30 01:04, Monte Goulding via use-livecode wrote:

I’m actually not sure I see the connection between the ide submodule
and the 8.1.6-rc-2.


Heh - the connection is indirect, however it is definitely there!

**The goal:

We want to do A/B testing on LiveCode's 'first run' experience. This 
experience has to go from finding the site, all the way through to 
downloading, installing, activating and actually using the product to 
ensure the data that we get is of the highest, and most useful quality. 
The experience any new user (who is being used as a guinea pig) has to 
be indistinguishable from all other new user's except for the specific 
test flow they have been allocated to.


**The problem:

Iteration on develop branch is too slow and we can't guarantee with a 
high degree of confidence that any one DP would be in any way suitable 
for a brand new user to use. (We still reserve the right to make 
absolutely blooping mistakes in develop DPs - obviously we try not to, 
but we need to be able to test out invasive changes somewhere, and that 
is where we currently can!).


We have a well-defined and tightly controlled process for our 
maintenance branch. It is really important that this is kept as it is, 
and it is definitely *not* the place to do any sort of testing of any 
features whatsoever.


For A/B testing to work, tests need to be able to be rolled out quickly, 
iterated quickly, and pulled quickly if they are unsuccessful, or 
indeed, ill-posed.


**The primary observation:

A/B testing is centered around the outermost, user-visible parts of any 
release. Specifically, the IDE and supporting materials. Any engine work 
that might be required will either be new (internal) additions to 
support user-visible work or bug fixes (almost always the latter).


**The proposed solution:

All A/B tests are built *upon* but not *into* the maintenance builds.

If a specific test *requires* a bug fix, it will be placed in first RC 
of the next maintenance build. If this means a specific test has to be 
deferred a short while it can be deployed then that is what must happen. 
(We have plenty of tests we could run, after all - it is not like we are 
going to run out anytime soon).


If a specific test *requires* an internal engine addition to achieve, 
then suitable analysis will be done to make sure it can and does have 
zero impact on the potential stability of a maintenance build. 
Basically, these things are constrained to internal features which are 
entirely 'bolted' on to the existing engine and have no interoperation 
with the existing code and ideally such things would be a widget/library 
or a similar extrinsic addition.


A test will be created by making a fork of the target maintenance 
release branch in the IDE repository. All work for the specific test 
happens on this branch. All active test branches are kept up to date, by 
merging progress of the underlying maintenance branch/release branch 
(e.g. develop-8.1 or release-8.1.7) into them.


Tests are not built into the maintenance releases - the entire IDE 
bundle for that test will be uploaded as a separate archive.


When a new user who is being put through a test generates a license, the 
license will be marked with the name of the test.


When the user activates and launches the IDE for the first time, the 
appropriate test (IDE) archive will be downloaded and *that* version of 
the IDE will be launched, rather than the one built into the release.


If a test is successful, it will be merged into the next *suitable* 
version.


For small entirely first-run related things this might well be a 
maintenance release (e.g. new first run tutorials, new materials, new 
default preferences for first-run users).


For larger things (such as autocomplete or handler lists) we will use a 
bump in *middle* version number of semver, and use a DP release to make 
sure we got it absolutely right.


Importantly the latter has no impact on what new users see. We can merge 
all successful tests into all future tests so we our test profiles build 
on what we have done before. i.e. New users will see the combined set of 
successful tests; whilst existing users will be able to help us finesse 
them and ensure that they are as good as they can be before appearing in 
a minor version update; rather than a maintenance update.


If a test is unsuccessful, the test just gets deleted, the code for it 
is never merged (but of course, we'll keep the code - it might be 
something we might want to test again in the future).


**Why it works:

The issue which occurred with 8.1.6-rc-2 was due to the fact we were 
iterating on the actual releases which existing users rely on. This 
approach means that existing users will not see, nor even have the code 
in their system for any of the tests which we run. We can keep the 
strict process for maintenance releases we have always had, whilst still 
using them to iterate rapidly in the first-run A/B testing side.


**What 

Re: gitter

[Brian Milby via use-livecode]

  
  

 I'm just now getting my head around how to set them up.SourceTree is 
recursive by default so my builds were fine.Took a little more playing 
around to set it up so I could contribute to the IDE and also build with my 
changes.(I had it set up as a separate workspace)
  

  
On the sub module I renamed origin to upstream and then added my fork as origin 
(remotes).I then changed develop to track upstream.This mirrors how 
LiveCode is set up.
  

  
As a test, I imported my sort branch on IDE and rebuilt.I then got the 
dictionary with the APIs sorted.This setup would have made my initial 
dictionary work so much easier (I was just hacking the code in the latest DP... 
figuring out how to generate the dictionary was fun...)
  

  
Thanks,
  
Brian
  

  
  

  
  
>   
> On Jul 29, 2017 at 5:10 PM,   (mailto:use-livecode@lists.runrev.com)>  wrote:
>   
>   
>   
>  On 07/29/2017 01:59 PM, Mark Waddingham via use-livecode wrote:  >>  FWIW I 
> have it on my phone and open on my desktop so I get  >>  notifications and 
> respond if I know the answer. Usually it’s “Have you  >>  updated 
> submodules?” ;-)  >   >  Its not just on Gitter that sentence gets uttered a 
> lot - it also occurs  >  frequently on our internal Slack dev channels! Have 
> I mentioned lately how much I hate submodules? -- Mark Wieder 
> ahsoftw...@gmail.com ___ 
> use-livecode mailing list use-livecode@lists.runrev.com Please visit this url 
> to subscribe, unsubscribe and manage your subscription preferences: 
> http://lists.runrev.com/mailman/listinfo/use-livecode  
>
>   
  
  
 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Monte Goulding via use-livecode]

> On 30 Jul 2017, at 8:59 am, Mark Waddingham via use-livecode 
>  wrote:
> 
> I'd rather suffer internal grumblings from our team due to having to have an 
> IDE submodule, than much larger shouts from our users when we make an error 
> like we did in 8.1.6-rc-2. I have a thick skin, I can happily ignore such 
> grumblings; less so very long, and very valid threads on the use-list :)

I’m actually not sure I see the connection between the ide submodule and the 
8.1.6-rc-2.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Mark Waddingham via use-livecode]

On 2017-07-30 00:53, Monte Goulding via use-livecode wrote:
On 30 Jul 2017, at 8:49 am, Mark Waddingham via use-livecode 
 wrote:


However, the IDE submodule is set to stay (despite various discussions 
about merging it internally - I've always said no, and I'm glad I 
have) - indeed, the fact it is a separate submodule helps to put in 
place a mechanism which ensures we won't have another 8.1.6-rc-2 type 
'balls-up' whilst doing user-testing :)


:-( expect continued internal grumblings on that...


I'd rather suffer internal grumblings from our team due to having to 
have an IDE submodule, than much larger shouts from our users when we 
make an error like we did in 8.1.6-rc-2. I have a thick skin, I can 
happily ignore such grumblings; less so very long, and very valid 
threads on the use-list :)


Warmest Regards,

Mark.


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Monte Goulding via use-livecode]

> On 30 Jul 2017, at 8:49 am, Mark Waddingham via use-livecode 
>  wrote:
> 
> However, the IDE submodule is set to stay (despite various discussions about 
> merging it internally - I've always said no, and I'm glad I have) - indeed, 
> the fact it is a separate submodule helps to put in place a mechanism which 
> ensures we won't have another 8.1.6-rc-2 type 'balls-up' whilst doing 
> user-testing :)

:-( expect continued internal grumblings on that...

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Mark Waddingham via use-livecode]

On 2017-07-30 00:10, Mark Wieder via use-livecode wrote:

Have I mentioned lately how much I hate submodules?


Have I mentioned lately how much I hate submodules? ;)

Actually, submodules actually do their job really quite well. They 
aren't ideal, but they do enforce modularity (hence the name ;)). We 
just need to get round to sorting out some tooling (local shell scripts 
/ git hooks) to help make sure they aren't quite so easy to forget about 
syncing properly.


That being said we are very gradually working towards eliminating the 
third-party submodule.


However, the IDE submodule is set to stay (despite various discussions 
about merging it internally - I've always said no, and I'm glad I have) 
- indeed, the fact it is a separate submodule helps to put in place a 
mechanism which ensures we won't have another 8.1.6-rc-2 type 'balls-up' 
whilst doing user-testing :)


[ Something which is also on my list to post on - you're vehemence on 
the subject which I must confess I cannot in anyway disagree with made 
me come up with a solution to the problem - necessity being the mother 
of invention and all! ]


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Mark Wieder via use-livecode]

On 07/29/2017 01:59 PM, Mark Waddingham via use-livecode wrote:


FWIW I have it on my phone and open on my desktop so I get
notifications and respond if I know the answer. Usually it’s “Have you
updated submodules?” ;-)


Its not just on Gitter that sentence gets uttered a lot - it also occurs 
frequently on our internal Slack dev channels!


Have I mentioned lately how much I hate submodules?

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Mark Waddingham via use-livecode]

On 2017-07-29 22:51, Monte Goulding via use-livecode wrote:

As we get more contributors gitter will become more active and you
will be able to answer many of the questions for each other. There’s
little point expecting a great deal of chatter if there’s only half a
dozen people outside the company that have built livecode from source.
FWIW I have it on my phone and open on my desktop so I get
notifications and respond if I know the answer. Usually it’s “Have you
updated submodules?” ;-)


Its not just on Gitter that sentence gets uttered a lot - it also occurs 
frequently on our internal Slack dev channels!


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Monte Goulding via use-livecode]

> On 30 Jul 2017, at 1:01 am, Mark Wieder via use-livecode 
>  wrote:
> 
> On 07/29/2017 01:44 AM, Mark Waddingham via use-livecode wrote:
>> P.S. None of us tend to sit on gitter.io  - we can only 
>> process so many simultaneous inputs - however gitter does send email 
>> notifications when someone posts something on there and usually it doesn't 
>> take too long for one of us to notice (weekends, notwithstanding!).
> 
> While I think the original idea for using gitter (after trying Slack first) 
> was to set up sort of an IM channel, I have stopped expecting it to be that 
> and instead I use it for conversations where I need some deeper or arcane 
> expertise and don't feel like cluttering up the uselist or the web forums 
> that would be of interest to nobody else. And, once I stopped expecting it to 
> be an IM channel, I have to say that whatever the subject, I have always 
> gotten immensely useful information from the team on gitter.


As we get more contributors gitter will become more active and you will be able 
to answer many of the questions for each other. There’s little point expecting 
a great deal of chatter if there’s only half a dozen people outside the company 
that have built livecode from source. FWIW I have it on my phone and open on my 
desktop so I get notifications and respond if I know the answer. Usually it’s 
“Have you updated submodules?” ;-)

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Mark Waddingham via use-livecode]

On 2017-07-29 21:00, Mark Wieder via use-livecode wrote:

Yeah. That's what I was trying to say.


I know - I just thought I'd take the opportunity to be a little more 
blunt about it since you gave me the hook to do so - i.e. gitter is not 
a route to get direct tech support from our engineers :)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Mark Wieder via use-livecode]

On 07/29/2017 08:38 AM, Mark Waddingham via use-livecode wrote:

Well Gitter itself is posed as more a technical/open source software dev thing 
I think.

Peter set it up as a more modern form of irc channels where people contributing 
to the open source project can interact with us and others along those lines.

For that it works really well. There can be a little bit of a delay in terms of 
getting an initial response sometimes - but when there's an active conversation 
going on we all try and be as responsive as we can.

We are likely to ask people to 'go elsewhere' if their questions / chat is not 
about actually contributing to the project - codewise in particular (or helping 
us do the dev work we do - e.g. Trying to diagnose a thorny problem in specific 
platform configurations!)


Yeah. That's what I was trying to say.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: gitter

[Mark Waddingham via use-livecode]

Well Gitter itself is posed as more a technical/open source software dev thing 
I think.

Peter set it up as a more modern form of irc channels where people contributing 
to the open source project can interact with us and others along those lines.

For that it works really well. There can be a little bit of a delay in terms of 
getting an initial response sometimes - but when there's an active conversation 
going on we all try and be as responsive as we can.

We are likely to ask people to 'go elsewhere' if their questions / chat is not 
about actually contributing to the project - codewise in particular (or helping 
us do the dev work we do - e.g. Trying to diagnose a thorny problem in specific 
platform configurations!)

Mark.

Sent from my iPhone

> On 29 Jul 2017, at 08:01, Mark Wieder via use-livecode 
>  wrote:
> 
>> On 07/29/2017 01:44 AM, Mark Waddingham via use-livecode wrote:
>> P.S. None of us tend to sit on gitter.io - we can only process so many 
>> simultaneous inputs - however gitter does send email notifications when 
>> someone posts something on there and usually it doesn't take too long for 
>> one of us to notice (weekends, notwithstanding!).
> 
> While I think the original idea for using gitter (after trying Slack first) 
> was to set up sort of an IM channel, I have stopped expecting it to be that 
> and instead I use it for conversations where I need some deeper or arcane 
> expertise and don't feel like cluttering up the uselist or the web forums 
> that would be of interest to nobody else. And, once I stopped expecting it to 
> be an IM channel, I have to say that whatever the subject, I have always 
> gotten immensely useful information from the team on gitter.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode