You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ctakes.apache.org by James Masanz <ma...@gmail.com> on 2017/01/27 19:23:58 UTC

(Re)introduce myself - James Masanz

Hi,

I'm James Masanz -- if you've been on the dev list for more than a couple
years, you might recognize my name from my previous contributions to
cTAKES, which include having been a release manager.

I've joined the Boston Children's Hospital NLP team. I will be devoting
significant energy to the next release of cTAKES, and I volunteer to be the
release manager for it.

My initial thoughts are that we could make the "fast dictionary lookup" be
the default dictionary lookup, incorporate the dictionary GUI from sandbox,
and call the release 4.0. I'm also interested in migrating the Wiki away
from Confluence to Apache's moin-moin instance. I'm sure there are other
things to include in the next release as well.

You'll be hearing more from me over the next few weeks as I review the list
of issues in Jira and get caught up with details of what's been going on
while I was less active here.

One thing I would like to track for release candidates would be a list of
what is tested on which platforms, which could be as simple as a post with
a matrix of src/bin/other vs. linux/windows/mac, and making sure we have at
least one volunteer to test the install and run of a pipeline for each
entry in the table. Future releases might expand on that to include
tracking multiple pipelines across environments, etc.

I'm happy I'm returning to being active in the cTAKES community!

-- James

Re: (Re)introduce myself - James Masanz

Posted by Pei Chen <pe...@wiredinformatics.com>.
James,
It’s really nice to hear from you again.  That sounds awesome!  Murali, Myself, and Sean F all volunteered to help out with the upcoming release.
A tag was already created in the repo as we would like to move things along previously.  As requested - waiting for everyone to get what they would like in the upcoming release committed into trunk (it’s been quite some time now).  
As soon as everyone is ready, we can easily tag and cut the release again.
I’ll be happy to do the thankless, grunt, administrative work of actually creating, and pushing the artifacts/archiving, etc. again.

—Pei

> On Jan 31, 2017, at 12:21 PM, James Masanz <ma...@gmail.com> wrote:
> 
> Sean, thanks for the background.
> 
> Pei, could you elaborate on who the existing RM volunteers are that you
> mentioned - to make sure everyone is on the same page regarding who those
> are?
> 
> I look forward to contributing to the next release of cTAKES, in whatever
> fashion. For this release and future releases, I'd like to be involved in
> making the documentation be better than the release before (but not
> over-documenting), and working to make it continually easier to get new
> users going. I think these would be great for the community and goals worth
> striving toward for each release.
> 
> One idea I'd like to explore is a verifier that could be run any time after
> an install, that would report to the user the results of a few basic checks
> - whether resources were downloaded and extracted successfully, whether
> cTAKES was moved after CTAKES_HOME was set, and other common debug needs.
> A user could post the report to the user list when asking for help with
> install/config issues.
> 
> I still need to finish catching up on what's been happening in the last
> year or two and take a detailed look at the issues list.
> 
> 
> 
> On Sat, Jan 28, 2017 at 1:38 PM, Finan, Sean <
> Sean.Finan@childrens.harvard.edu> wrote:
> 
>> Hi Pei,
>> 
>> I am a little taken back by your statement:
>>> I do not see an need for BCH to override existing volunteers.
>> 
>> From what James  wrote, I don't get the feeling that he is trying to
>> override other RM volunteers or in any way take control of the release.
>> His email stated specifically that he is volunteering to be the release
>> manager, not demanding the position.  Also, since by his own admission
>> James has been away, he may not be aware that anybody else has fully
>> assumed the role.  Is that indeed the case?  Because I had volunteered to
>> be Co-RM ...  For the benefit of James and others, some background is below.
>> 
>> On October 14th Murali Nagendranath volunteered to be the RM for a 3.2.3
>> release.  I replied:
>>> Hi Murali,  I appreciate the volunteerism!    ....   When a release is
>> being cut, I would like to be heavily involved.  Co-release managers?
>> 
>> My offer to share the burden received no reply.
>> 
>> Six or so weeks later on December 5th Murali asked the devlist:
>>> I wanted to check to see if there are objections to creating a 3.2.3 tag
>> of trunk now to prepare for a 3.2.3-rc1?
>> 
>> This got some pushback, which should be a valued part of the open
>> process.  Positive movement was made over the next 48 hours to start to get
>> things rolling toward resolving the noted problems with an immediate
>> release - in large part by you (cheers).
>> 
>> 9 days later on December 14th you wrote a report to the Apache board
>> containing:
>>> ## Issues:
>>> - The majority of the committee has been working very hard to push
>> forward the next release since has been almost 2 years since the last
>> release as pointed out in the last report.  There are volunteers and an RM
>> already stepped forward and started the process. However, there is a small
>> group which differs in opinion and prefers to delay/block the critical
>> minor/patch release
>> 
>> To be honest, I'm not sure that this is an accurate representation of the
>> efforts, number of RM volunteers or size and impact of a new ctakes
>> release.   It doesn't seem to paint the "small group" in a very favorable
>> light.  I am not trying to antagonize, I am just going over what is
>> publicly available in the devlist emails.
>> 
>> 
>> In a deeper exploration of the history, this was not the first round of
>> discussion on a 3.2.3 release.  Over a year ago on November 18th 2015 you
>> tried to get the ball rolling:
>>> It looks like there have been a lot of progress in Jira's.  What do
>> folks think of preparing a cut for the next release- would be nice to get
>> one more out before holidays/end of the year?
>>> I'll be happy to volunteer to be RM again.
>> 
>> I agreed with your assessment, thought that the software was in a good
>> state for a release, and was happy that you volunteered to be RM as I
>> indicated the next day:
>>> Hi Pei, thanks ...
>>> I say in my bazaar way: release early, release often ...
>>> +1 for bumps and release ...
>> 
>> I think that we all had great expectations, and your December report to
>> the Apache board included:
>>> - The committee is actively preparing for the next release 3.2.3
>> (Tentatively targeted for Dec)
>> 
>> Unfortunately by the March report to the Apache board the release was not
>> cut:
>>> - The committee is actively preparing features for the next release
>> 3.2.3.  Folks are continuing after a busy holiday quarter.
>> 
>> By the time of the June report the project was (probably) no longer in a
>> releasable state, and your report contained no mention of it.  The
>> September report had the line item:
>>> - Committee will schedule a release as soon as they feel it's ready;
>> previously pushed back as there hasn't been major features/changes to code
>> base yet.  Committers will be able to volunteer to be RM as soon as
>> committee/community is ready for a new release.
>> 
>> I understand that because of the report you may personally feel like you
>> are under the gun to get something out there asap.  As Murali is (I
>> believe) your employee/coworker you may have faith that he will get things
>> done.  But I would like to point out the plural in your statement
>> "Committers will be able ..."  It seems that James is allowed to volunteer
>> to be an RM.  I would also like to remind that 3 months ago I volunteered
>> to be Co-RM and would love to have James' help - not just because he has
>> previously been part of the release process, but also because he is one of
>> the original visionaries of ctakes!
>> 
>> Please take this kindly,
>> Sean
>> 
>> 
>> -----Original Message-----
>> From: Pei Chen [mailto:pei.chen@wiredinformatics.com]
>> Sent: Friday, January 27, 2017 2:29 PM
>> To: dev@ctakes.apache.org
>> Subject: Re: (Re)introduce myself - James Masanz
>> 
>> Welcome back James!  Good to hear from you again.
>> Out of respect for the others in the community who already volunteered to
>> be RM, I do not see an need for BCH to override existing volunteers. Unless
>> they unable or unwilling.
>> Would you/others agree?
>> 
>> Sent from my iPhone
>> 
>>> On Jan 27, 2017, at 2:23 PM, James Masanz <ma...@gmail.com>
>> wrote:
>>> 
>>> Hi,
>>> 
>>> I'm James Masanz -- if you've been on the dev list for more than a
>>> couple years, you might recognize my name from my previous
>>> contributions to cTAKES, which include having been a release manager.
>>> 
>>> I've joined the Boston Children's Hospital NLP team. I will be
>>> devoting significant energy to the next release of cTAKES, and I
>>> volunteer to be the release manager for it.
>>> 
>>> My initial thoughts are that we could make the "fast dictionary
>>> lookup" be the default dictionary lookup, incorporate the dictionary
>>> GUI from sandbox, and call the release 4.0. I'm also interested in
>>> migrating the Wiki away from Confluence to Apache's moin-moin
>>> instance. I'm sure there are other things to include in the next release
>> as well.
>>> 
>>> You'll be hearing more from me over the next few weeks as I review the
>>> list of issues in Jira and get caught up with details of what's been
>>> going on while I was less active here.
>>> 
>>> One thing I would like to track for release candidates would be a list
>>> of what is tested on which platforms, which could be as simple as a
>>> post with a matrix of src/bin/other vs. linux/windows/mac, and making
>>> sure we have at least one volunteer to test the install and run of a
>>> pipeline for each entry in the table. Future releases might expand on
>>> that to include tracking multiple pipelines across environments, etc.
>>> 
>>> I'm happy I'm returning to being active in the cTAKES community!
>>> 
>>> -- James
>> 


Re: (Re)introduce myself - James Masanz

Posted by James Masanz <ma...@gmail.com>.
Sean, thanks for the background.

Pei, could you elaborate on who the existing RM volunteers are that you
mentioned - to make sure everyone is on the same page regarding who those
are?

I look forward to contributing to the next release of cTAKES, in whatever
fashion. For this release and future releases, I'd like to be involved in
making the documentation be better than the release before (but not
over-documenting), and working to make it continually easier to get new
users going. I think these would be great for the community and goals worth
striving toward for each release.

One idea I'd like to explore is a verifier that could be run any time after
an install, that would report to the user the results of a few basic checks
- whether resources were downloaded and extracted successfully, whether
cTAKES was moved after CTAKES_HOME was set, and other common debug needs.
A user could post the report to the user list when asking for help with
install/config issues.

I still need to finish catching up on what's been happening in the last
year or two and take a detailed look at the issues list.



On Sat, Jan 28, 2017 at 1:38 PM, Finan, Sean <
Sean.Finan@childrens.harvard.edu> wrote:

> Hi Pei,
>
> I am a little taken back by your statement:
> > I do not see an need for BCH to override existing volunteers.
>
> From what James  wrote, I don't get the feeling that he is trying to
> override other RM volunteers or in any way take control of the release.
> His email stated specifically that he is volunteering to be the release
> manager, not demanding the position.  Also, since by his own admission
> James has been away, he may not be aware that anybody else has fully
> assumed the role.  Is that indeed the case?  Because I had volunteered to
> be Co-RM ...  For the benefit of James and others, some background is below.
>
> On October 14th Murali Nagendranath volunteered to be the RM for a 3.2.3
> release.  I replied:
> > Hi Murali,  I appreciate the volunteerism!    ....   When a release is
> being cut, I would like to be heavily involved.  Co-release managers?
>
> My offer to share the burden received no reply.
>
> Six or so weeks later on December 5th Murali asked the devlist:
> > I wanted to check to see if there are objections to creating a 3.2.3 tag
> of trunk now to prepare for a 3.2.3-rc1?
>
> This got some pushback, which should be a valued part of the open
> process.  Positive movement was made over the next 48 hours to start to get
> things rolling toward resolving the noted problems with an immediate
> release - in large part by you (cheers).
>
> 9 days later on December 14th you wrote a report to the Apache board
> containing:
> >## Issues:
> >- The majority of the committee has been working very hard to push
> forward the next release since has been almost 2 years since the last
> release as pointed out in the last report.  There are volunteers and an RM
> already stepped forward and started the process. However, there is a small
> group which differs in opinion and prefers to delay/block the critical
> minor/patch release
>
> To be honest, I'm not sure that this is an accurate representation of the
> efforts, number of RM volunteers or size and impact of a new ctakes
> release.   It doesn't seem to paint the "small group" in a very favorable
> light.  I am not trying to antagonize, I am just going over what is
> publicly available in the devlist emails.
>
>
> In a deeper exploration of the history, this was not the first round of
> discussion on a 3.2.3 release.  Over a year ago on November 18th 2015 you
> tried to get the ball rolling:
> > It looks like there have been a lot of progress in Jira's.  What do
> folks think of preparing a cut for the next release- would be nice to get
> one more out before holidays/end of the year?
> >I'll be happy to volunteer to be RM again.
>
> I agreed with your assessment, thought that the software was in a good
> state for a release, and was happy that you volunteered to be RM as I
> indicated the next day:
> >Hi Pei, thanks ...
> > I say in my bazaar way: release early, release often ...
> > +1 for bumps and release ...
>
> I think that we all had great expectations, and your December report to
> the Apache board included:
> > - The committee is actively preparing for the next release 3.2.3
> (Tentatively targeted for Dec)
>
> Unfortunately by the March report to the Apache board the release was not
> cut:
> >- The committee is actively preparing features for the next release
> 3.2.3.  Folks are continuing after a busy holiday quarter.
>
> By the time of the June report the project was (probably) no longer in a
> releasable state, and your report contained no mention of it.  The
> September report had the line item:
> > - Committee will schedule a release as soon as they feel it's ready;
> previously pushed back as there hasn't been major features/changes to code
> base yet.  Committers will be able to volunteer to be RM as soon as
> committee/community is ready for a new release.
>
> I understand that because of the report you may personally feel like you
> are under the gun to get something out there asap.  As Murali is (I
> believe) your employee/coworker you may have faith that he will get things
> done.  But I would like to point out the plural in your statement
> "Committers will be able ..."  It seems that James is allowed to volunteer
> to be an RM.  I would also like to remind that 3 months ago I volunteered
> to be Co-RM and would love to have James' help - not just because he has
> previously been part of the release process, but also because he is one of
> the original visionaries of ctakes!
>
> Please take this kindly,
> Sean
>
>
> -----Original Message-----
> From: Pei Chen [mailto:pei.chen@wiredinformatics.com]
> Sent: Friday, January 27, 2017 2:29 PM
> To: dev@ctakes.apache.org
> Subject: Re: (Re)introduce myself - James Masanz
>
> Welcome back James!  Good to hear from you again.
> Out of respect for the others in the community who already volunteered to
> be RM, I do not see an need for BCH to override existing volunteers. Unless
> they unable or unwilling.
> Would you/others agree?
>
> Sent from my iPhone
>
> > On Jan 27, 2017, at 2:23 PM, James Masanz <ma...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > I'm James Masanz -- if you've been on the dev list for more than a
> > couple years, you might recognize my name from my previous
> > contributions to cTAKES, which include having been a release manager.
> >
> > I've joined the Boston Children's Hospital NLP team. I will be
> > devoting significant energy to the next release of cTAKES, and I
> > volunteer to be the release manager for it.
> >
> > My initial thoughts are that we could make the "fast dictionary
> > lookup" be the default dictionary lookup, incorporate the dictionary
> > GUI from sandbox, and call the release 4.0. I'm also interested in
> > migrating the Wiki away from Confluence to Apache's moin-moin
> > instance. I'm sure there are other things to include in the next release
> as well.
> >
> > You'll be hearing more from me over the next few weeks as I review the
> > list of issues in Jira and get caught up with details of what's been
> > going on while I was less active here.
> >
> > One thing I would like to track for release candidates would be a list
> > of what is tested on which platforms, which could be as simple as a
> > post with a matrix of src/bin/other vs. linux/windows/mac, and making
> > sure we have at least one volunteer to test the install and run of a
> > pipeline for each entry in the table. Future releases might expand on
> > that to include tracking multiple pipelines across environments, etc.
> >
> > I'm happy I'm returning to being active in the cTAKES community!
> >
> > -- James
>

Re: (Re)introduce myself - James Masanz

Posted by Andrey Kurdumov <ka...@googlemail.com>.
Hi James,

Good to hear that +1 member join the cTakes.
Hopefully we will see new release soon.



2017-01-29 0:38 GMT+06:00 Finan, Sean <Se...@childrens.harvard.edu>:

> Hi Pei,
>
> I am a little taken back by your statement:
> > I do not see an need for BCH to override existing volunteers.
>
> From what James  wrote, I don't get the feeling that he is trying to
> override other RM volunteers or in any way take control of the release.
> His email stated specifically that he is volunteering to be the release
> manager, not demanding the position.  Also, since by his own admission
> James has been away, he may not be aware that anybody else has fully
> assumed the role.  Is that indeed the case?  Because I had volunteered to
> be Co-RM ...  For the benefit of James and others, some background is below.
>
> On October 14th Murali Nagendranath volunteered to be the RM for a 3.2.3
> release.  I replied:
> > Hi Murali,  I appreciate the volunteerism!    ....   When a release is
> being cut, I would like to be heavily involved.  Co-release managers?
>
> My offer to share the burden received no reply.
>
> Six or so weeks later on December 5th Murali asked the devlist:
> > I wanted to check to see if there are objections to creating a 3.2.3 tag
> of trunk now to prepare for a 3.2.3-rc1?
>
> This got some pushback, which should be a valued part of the open
> process.  Positive movement was made over the next 48 hours to start to get
> things rolling toward resolving the noted problems with an immediate
> release - in large part by you (cheers).
>
> 9 days later on December 14th you wrote a report to the Apache board
> containing:
> >## Issues:
> >- The majority of the committee has been working very hard to push
> forward the next release since has been almost 2 years since the last
> release as pointed out in the last report.  There are volunteers and an RM
> already stepped forward and started the process. However, there is a small
> group which differs in opinion and prefers to delay/block the critical
> minor/patch release
>
> To be honest, I'm not sure that this is an accurate representation of the
> efforts, number of RM volunteers or size and impact of a new ctakes
> release.   It doesn't seem to paint the "small group" in a very favorable
> light.  I am not trying to antagonize, I am just going over what is
> publicly available in the devlist emails.
>
>
> In a deeper exploration of the history, this was not the first round of
> discussion on a 3.2.3 release.  Over a year ago on November 18th 2015 you
> tried to get the ball rolling:
> > It looks like there have been a lot of progress in Jira's.  What do
> folks think of preparing a cut for the next release- would be nice to get
> one more out before holidays/end of the year?
> >I'll be happy to volunteer to be RM again.
>
> I agreed with your assessment, thought that the software was in a good
> state for a release, and was happy that you volunteered to be RM as I
> indicated the next day:
> >Hi Pei, thanks ...
> > I say in my bazaar way: release early, release often ...
> > +1 for bumps and release ...
>
> I think that we all had great expectations, and your December report to
> the Apache board included:
> > - The committee is actively preparing for the next release 3.2.3
> (Tentatively targeted for Dec)
>
> Unfortunately by the March report to the Apache board the release was not
> cut:
> >- The committee is actively preparing features for the next release
> 3.2.3.  Folks are continuing after a busy holiday quarter.
>
> By the time of the June report the project was (probably) no longer in a
> releasable state, and your report contained no mention of it.  The
> September report had the line item:
> > - Committee will schedule a release as soon as they feel it's ready;
> previously pushed back as there hasn't been major features/changes to code
> base yet.  Committers will be able to volunteer to be RM as soon as
> committee/community is ready for a new release.
>
> I understand that because of the report you may personally feel like you
> are under the gun to get something out there asap.  As Murali is (I
> believe) your employee/coworker you may have faith that he will get things
> done.  But I would like to point out the plural in your statement
> "Committers will be able ..."  It seems that James is allowed to volunteer
> to be an RM.  I would also like to remind that 3 months ago I volunteered
> to be Co-RM and would love to have James' help - not just because he has
> previously been part of the release process, but also because he is one of
> the original visionaries of ctakes!
>
> Please take this kindly,
> Sean
>
>
> -----Original Message-----
> From: Pei Chen [mailto:pei.chen@wiredinformatics.com]
> Sent: Friday, January 27, 2017 2:29 PM
> To: dev@ctakes.apache.org
> Subject: Re: (Re)introduce myself - James Masanz
>
> Welcome back James!  Good to hear from you again.
> Out of respect for the others in the community who already volunteered to
> be RM, I do not see an need for BCH to override existing volunteers. Unless
> they unable or unwilling.
> Would you/others agree?
>
> Sent from my iPhone
>
> > On Jan 27, 2017, at 2:23 PM, James Masanz <ma...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > I'm James Masanz -- if you've been on the dev list for more than a
> > couple years, you might recognize my name from my previous
> > contributions to cTAKES, which include having been a release manager.
> >
> > I've joined the Boston Children's Hospital NLP team. I will be
> > devoting significant energy to the next release of cTAKES, and I
> > volunteer to be the release manager for it.
> >
> > My initial thoughts are that we could make the "fast dictionary
> > lookup" be the default dictionary lookup, incorporate the dictionary
> > GUI from sandbox, and call the release 4.0. I'm also interested in
> > migrating the Wiki away from Confluence to Apache's moin-moin
> > instance. I'm sure there are other things to include in the next release
> as well.
> >
> > You'll be hearing more from me over the next few weeks as I review the
> > list of issues in Jira and get caught up with details of what's been
> > going on while I was less active here.
> >
> > One thing I would like to track for release candidates would be a list
> > of what is tested on which platforms, which could be as simple as a
> > post with a matrix of src/bin/other vs. linux/windows/mac, and making
> > sure we have at least one volunteer to test the install and run of a
> > pipeline for each entry in the table. Future releases might expand on
> > that to include tracking multiple pipelines across environments, etc.
> >
> > I'm happy I'm returning to being active in the cTAKES community!
> >
> > -- James
>

RE: (Re)introduce myself - James Masanz

Posted by "Finan, Sean" <Se...@childrens.harvard.edu>.
Hi Pei,

I am a little taken back by your statement:
> I do not see an need for BCH to override existing volunteers.

From what James  wrote, I don't get the feeling that he is trying to override other RM volunteers or in any way take control of the release.  His email stated specifically that he is volunteering to be the release manager, not demanding the position.  Also, since by his own admission James has been away, he may not be aware that anybody else has fully assumed the role.  Is that indeed the case?  Because I had volunteered to be Co-RM ...  For the benefit of James and others, some background is below.

On October 14th Murali Nagendranath volunteered to be the RM for a 3.2.3 release.  I replied:
> Hi Murali,  I appreciate the volunteerism!    ....   When a release is being cut, I would like to be heavily involved.  Co-release managers?

My offer to share the burden received no reply.

Six or so weeks later on December 5th Murali asked the devlist:
> I wanted to check to see if there are objections to creating a 3.2.3 tag of trunk now to prepare for a 3.2.3-rc1?

This got some pushback, which should be a valued part of the open process.  Positive movement was made over the next 48 hours to start to get things rolling toward resolving the noted problems with an immediate release - in large part by you (cheers).

9 days later on December 14th you wrote a report to the Apache board containing:
>## Issues:
>- The majority of the committee has been working very hard to push forward the next release since has been almost 2 years since the last release as pointed out in the last report.  There are volunteers and an RM already stepped forward and started the process. However, there is a small group which differs in opinion and prefers to delay/block the critical minor/patch release

To be honest, I'm not sure that this is an accurate representation of the efforts, number of RM volunteers or size and impact of a new ctakes release.   It doesn't seem to paint the "small group" in a very favorable light.  I am not trying to antagonize, I am just going over what is publicly available in the devlist emails.


In a deeper exploration of the history, this was not the first round of discussion on a 3.2.3 release.  Over a year ago on November 18th 2015 you tried to get the ball rolling:
> It looks like there have been a lot of progress in Jira's.  What do folks think of preparing a cut for the next release- would be nice to get one more out before holidays/end of the year? 
>I'll be happy to volunteer to be RM again.

I agreed with your assessment, thought that the software was in a good state for a release, and was happy that you volunteered to be RM as I indicated the next day:
>Hi Pei, thanks ...
> I say in my bazaar way: release early, release often ...  
> +1 for bumps and release ...

I think that we all had great expectations, and your December report to the Apache board included:
> - The committee is actively preparing for the next release 3.2.3 (Tentatively targeted for Dec)

Unfortunately by the March report to the Apache board the release was not cut:
>- The committee is actively preparing features for the next release 3.2.3.  Folks are continuing after a busy holiday quarter.

By the time of the June report the project was (probably) no longer in a releasable state, and your report contained no mention of it.  The September report had the line item:
> - Committee will schedule a release as soon as they feel it's ready; previously pushed back as there hasn't been major features/changes to code base yet.  Committers will be able to volunteer to be RM as soon as committee/community is ready for a new release.

I understand that because of the report you may personally feel like you are under the gun to get something out there asap.  As Murali is (I believe) your employee/coworker you may have faith that he will get things done.  But I would like to point out the plural in your statement "Committers will be able ..."  It seems that James is allowed to volunteer to be an RM.  I would also like to remind that 3 months ago I volunteered to be Co-RM and would love to have James' help - not just because he has previously been part of the release process, but also because he is one of the original visionaries of ctakes!

Please take this kindly,
Sean


-----Original Message-----
From: Pei Chen [mailto:pei.chen@wiredinformatics.com] 
Sent: Friday, January 27, 2017 2:29 PM
To: dev@ctakes.apache.org
Subject: Re: (Re)introduce myself - James Masanz

Welcome back James!  Good to hear from you again. 
Out of respect for the others in the community who already volunteered to be RM, I do not see an need for BCH to override existing volunteers. Unless they unable or unwilling.
Would you/others agree? 

Sent from my iPhone

> On Jan 27, 2017, at 2:23 PM, James Masanz <ma...@gmail.com> wrote:
> 
> Hi,
> 
> I'm James Masanz -- if you've been on the dev list for more than a 
> couple years, you might recognize my name from my previous 
> contributions to cTAKES, which include having been a release manager.
> 
> I've joined the Boston Children's Hospital NLP team. I will be 
> devoting significant energy to the next release of cTAKES, and I 
> volunteer to be the release manager for it.
> 
> My initial thoughts are that we could make the "fast dictionary 
> lookup" be the default dictionary lookup, incorporate the dictionary 
> GUI from sandbox, and call the release 4.0. I'm also interested in 
> migrating the Wiki away from Confluence to Apache's moin-moin 
> instance. I'm sure there are other things to include in the next release as well.
> 
> You'll be hearing more from me over the next few weeks as I review the 
> list of issues in Jira and get caught up with details of what's been 
> going on while I was less active here.
> 
> One thing I would like to track for release candidates would be a list 
> of what is tested on which platforms, which could be as simple as a 
> post with a matrix of src/bin/other vs. linux/windows/mac, and making 
> sure we have at least one volunteer to test the install and run of a 
> pipeline for each entry in the table. Future releases might expand on 
> that to include tracking multiple pipelines across environments, etc.
> 
> I'm happy I'm returning to being active in the cTAKES community!
> 
> -- James

Re: (Re)introduce myself - James Masanz

Posted by Pei Chen <pe...@wiredinformatics.com>.
Welcome back James!  Good to hear from you again. 
Out of respect for the others in the community who already volunteered to be RM, I do not see an need for BCH to override existing volunteers. Unless they unable or unwilling.
Would you/others agree? 

Sent from my iPhone

> On Jan 27, 2017, at 2:23 PM, James Masanz <ma...@gmail.com> wrote:
> 
> Hi,
> 
> I'm James Masanz -- if you've been on the dev list for more than a couple
> years, you might recognize my name from my previous contributions to
> cTAKES, which include having been a release manager.
> 
> I've joined the Boston Children's Hospital NLP team. I will be devoting
> significant energy to the next release of cTAKES, and I volunteer to be the
> release manager for it.
> 
> My initial thoughts are that we could make the "fast dictionary lookup" be
> the default dictionary lookup, incorporate the dictionary GUI from sandbox,
> and call the release 4.0. I'm also interested in migrating the Wiki away
> from Confluence to Apache's moin-moin instance. I'm sure there are other
> things to include in the next release as well.
> 
> You'll be hearing more from me over the next few weeks as I review the list
> of issues in Jira and get caught up with details of what's been going on
> while I was less active here.
> 
> One thing I would like to track for release candidates would be a list of
> what is tested on which platforms, which could be as simple as a post with
> a matrix of src/bin/other vs. linux/windows/mac, and making sure we have at
> least one volunteer to test the install and run of a pipeline for each
> entry in the table. Future releases might expand on that to include
> tracking multiple pipelines across environments, etc.
> 
> I'm happy I'm returning to being active in the cTAKES community!
> 
> -- James