 Okay, so this is the January call for share dev community the first one of the new year 2019. So welcome all. Happy new year. Happy new year. As you can see, let me put the link to the agenda in both the chat and discord so folks have access to that. Okay, and then go ahead and add your names in please to the attendees. I'm just looking to see do we have anyone new on the call that hasn't been done before? Sounds like no. Okay, so jumping right in anyone doesn't have to be just one person willing to jot in notes as we go. I can do it. Thank you, Cam. Okay, so the primary thing I wanted to start from today was looking at new project board that we just created yesterday, day before yesterday. So not not super long ago. Let me open that up. Okay, it is just going to do that. Great. So the I guess that I'm going to pause quickly so that I think everyone knows everyone's we have that's on the call Ryan usual suspects Harsh, Cam, Jeff, et cetera. And Judy, you're I saw you're on the call as well. I am I can't get my video to work for some reason. Okay, okay. Here I am. Okay. All right. So so we so what we have here is a slight improvement we hope from how it how things have been listed out have issues tracked within here. So in the past we had one repo within share research that had its own GitHub project. So if you and that was attached to this share and repo and it pretty much was primarily serving the at least for the moment serving the purpose of track tracking as repo to have that. So instead we now have a project that's tied to the parent organization for all the repos and get back to it. So now then it just has repos and within the organization link to it. So any issues that are attached to those repos, they do show up here. So like we didn't actually migrate any of the existing issues to anything else. Just by linking the repos in it was able to see all of the issues that have been that we've been tracking against to date. So the main thing that we've added since then is looking at how to attach some milestones to work against here. So not just at the granular task level but also at one level above that. And these ones that are just here to start with certainly doesn't need to be the list forever but can be tweaked that what we have right now is initial suite of share red nodes to build a metadata processing workflow. So things the work that's been ongoing. Then a single share index instance running that can index data from a share red flow or multiple flows that can push to it. And then for the moment having those instances be networked is a separate milestone. So two or more nodes can be networked together. So first we can just focus on making sure we can have an index of things and then those can can share data with one another. Then the other two that are in here a general reporting analysis dashboard that can display data from a share index and then also the essentially the runtime environment. Actually I think they've changed that wording now as we're talking. So share runtime environment for a QMS job. So anytime we define a flow we don't want to be limited by you know a single client instance of share red. We want to be able to have those B flows that they can be packaged up and executed. And there is some movement on that that we're excited about but any questions on this piece or comments before we move along. Let me make sure there's nothing in the chat as well. Okay so I assume this all sounds good. One thing I was looking at that I think deserve some other opinions is how we would track associated sub tasks to these things. I just added a couple examples in here. There's one so within these organizational level projects there isn't the notion of being able to set a milestone like there is for if you're familiar with GitHub projects at the repo level you can set a milestone and then say okay these are all the issues that need to be done before the milestone is done. There isn't that notion at the organization level. There is however still the ability to attach labels to things so you can group things by a particular label so I click that label and it just goes to that that one ticket that's attached to it now. Something I noticed that Harsh had done in this issue actually was he had created a checklist and it looked like he was just doing it with markdown. So that is another example that I added in here where I just replicated the formatting he was using to say okay this is our checklist. The downside to that is it is its own list that is you know not actually tied to any particular issue so it won't automatically be checked when a related issue is done but maybe we could also if you added something we could experiment if you actually like put in the URI or the URL to the issue if it will show it as crossed out. I don't know if GitHub will do that or not when you finish it but that would be something to experiment with. Any opinions on like how what you like or dislike about being able to track these sub-tests? I like the idea of using labels but I don't know if you can do the same like can you sync up labels across repositories? I think so like as a so like of this one for example I think it is keeping the same label I when I added the label I did add it through this level view that would be a good question. Because if that is possible then you can just on the on the on the organization level you can just say filter by label and say label or filter by labels print one and then it shows you all the issues in all the different repositories with that label. Yeah it looks because I'm looking at it not at the organization level but at this level and it looks like it does have that label intact like if I look at it here so this is not the organization. Yeah it looks like it does it works at each nested level. Yeah so that is useful. Yeah it must be organization-wide when you add labels in here. Yeah that would be great so the filter cards search dialogue on the top over there just above the in review column you can just say label colon whichever label you want to filter and it'll show you all those cards. Oh can you attach one of these cards to it as well? I didn't look at that but these these things can be converted to issues as well so it doesn't have to be limited by that. So that's probably an open question that we don't have to answer now. Yeah so that would be something to add to the action item list just to investigate quickly about whether those labels can then be attached in that way. Attached to cards was it. Yeah it looked like it was pretty pretty straightforward just to just to convert any one of these to an issue. I guess the question would be if it's converted if it's converted to issue it probably would then maybe want to be tied to a particular repo I'm guessing because these cards are just at this project level as far as I can tell. Yep okay anything else on that point? Okay so let's go back to the list so that first one the share read runtime environment queuing so that that is something that Harsh can you give an update on this one? Sure so I was working through the investigating if if node read can be used as a distributed fashion if we can have like an engine running remotely and have flows running in those remote engines. So it seems like the community is and the core contributors are actively working on a new release. This is 4.28.0 and it was planned the plan of the release was planned for early January but it's some because it's like a major I wouldn't say refactor but a re-architecture of the code base restructuring of the code base they are doing a different fashion of release and they're doing more beta releases so just two hours back today they released beta 3 and it seems like they're slightly delayed but still very much on track to get the final release as soon as possible there is no dates that is being mentioned anywhere as to when the final release will be there but I would guess like by end of this month more optimistically maybe end of this month is when they would have a final release there's I think seven or eight issues in the GitHub repository that they need to work through to be able to do a final release. I have documented some of my findings in two GitHub issues and where it talks more in detail about what is happening in the code and some of that is a little bit is a little bit of knowledge that maybe Ram and Ryan and Cam already know about could be useful for others if you see you know any misinterpretation on my behalf or a missing piece of information feel free to add over there but what I was hoping through this exercise is for to do some finding bring it to the group and talk about it and say okay does this make sense for our needs and so I've tried to put that in a little bit of words that I picked up from the Node-RED community about the 020 release as well as in conversation with Jeff so I am going to take that link and put it in the document so it would be interesting to see what everybody else thinks about the use cases that have been put up in the Node-RED design for 0.20 and if those fit our needs partially or completely as yet to be identified but from my standpoint I feel like this is a very promising release and we should you know wait for the final final release of 0.20 and see how far that can get us in terms of what we want to do with ShareRED. I just found the link that you shared the other day about uh what the different what the differences are for this release so it and just just by their like high level description didn't make sense to me until I looked at these these specific specific use cases um so like the one that seems to map the best to us is this what scaled one that we had talked about just so a Node-RED flow is that in one place when deploy to get sent to multiple run times to provide horizontal scaling um cussing extra added behind the boy etc and then also like the distributed gets carbon different parts puts different run time either look or mode so so this is then theoretically possible um to have things that operate more as a server versus a client that is an editor that kind of has everything wrapped up with it so that so that's the core of it is is splitting all of these things up and yeah multiple parts yeah you're absolutely right like just being able to not want the runtime uh when you're editing it and not and vice versa like not have the editor when you're just running a flow is is what makes it a little bit uh easier to wrap in our head uh saying yeah this is client this is server um and it also makes it very lightweight um I I know in this release they're doing uh more upgrades and minor uh adding more buttons on the UI to make it easier to do like collaborative uh work work flow development uh and they already have the projects feature in Node-RED so I think we're already doing that in share read but now with this release they are adding more uh easier navigation capabilities on the editor itself in that all are gone uh on a specific flow it becomes much more easier to use one UI one editor uh to do share development for the flow and then deploy it to a remote cluster of engines yeah so so also the to give more back on so part of the question that before we had heard that this was just going to be released it was wondering whether we whether we would need to create some kind of interim solution kind of assuming that this is the best long-term path but in order to keep moving ourselves and so it so it sounds like so so like from your standpoint harsh does it seem like this is moving fast enough for us to yeah timeline wise I think this is moving fast enough and I think the community is large enough to keep it moving forward and it's still very active um and and so we want to keep a tab on like are people continuing to use Node-RED in the future uh if that is something uh which changes then it puts the maintainability of this kind of an open source application into question uh and its stability into question uh there are in terms of like long-term feasibility of using Node-RED itself I think there are other questions we need to answer is uh does it fit our needs uh first uh and that would mean like in once we have the final release we start playing around uh fleshing out all the use cases have a cluster of um engines and do uh do like sessions uh to just go through the motions of building a workflow deploying it seeing the changes again building it again and finding out what works and what doesn't work for us the second piece uh the second piece of this is like also to understand and make sure how how how we're going to maintain the infrastructure and how we're going to do the deployment and maintenance of that if we are using like a shared cluster and that is more like our uh that is more of a question for us internally uh amongst the share research contributors as to how we want to do this and who takes ownership of that but those are the questions I think we should be able to answer like once we get into doing more with the latest release of Node-RED okay that's great any any additional comments for questions okay all right so then the next thing so so again looking at our list here what was wrong on here we go so the so the assessment here in terms of like order of priority of when we can work on these things was that that we should the initial guess was that we should continue to focus on this initial suite of shared nodes um so again this was just the stab I took it trying to start seed that list of tasks um eliciting the initial set of shared nodes uh I think that's where we want to get to uh because at the moment like what the flows we've created to date with the nodes that are custom to that I would still consider those you know not very very much pre-release in terms of robustness etc so so so the next step is then to to start generating that list of okay these are the nodes that we want to have in our toolkit that then for common operations that we then just want to have available as someone is looking to build a new flow um and this one Jeff we can talk about later this actually came up in a Prescuti grant related meeting this morning as as a potential use of this where it was kind of where it was actually a really natural fit in terms of looking to map um metadata from one source repository to a target repository good so so I think that that there may be some some clear alignment there that that we had not thought about yet okay so looking at this initial list then um I had promised that I would start to see this but I didn't get to yet so I will start now I will own that so the one one that I think the one obvious one is uh parsing names is one um there are others like it I think as as we've gone through the working through the different use cases there have been a few different common operations that have emerged um um another one is uh branching on uh multiple fields and wrapping up in single objects that's pretty verbose but you can of course be updated go um okay anything anyone else can think of that that we should start adding here jeff sounded like you had yeah the let's see um oai p m h seems like an obvious uh node want to do a gender analysis what's that we still want to do gender analysis is a possibility it wouldn't be that robust just because maybe we could make a robust one I guess well that would that be a a flow or or like example flow or example node so being your analysis okay um let's see there were some others like uh load metadata mapping there's another one that was already starting to wrap up into those in the flow I was looking at load csv data is another one maybe this is a good enough list to start with for now yeah I think that's fine yeah so then the idea here is we would then create issues for each of these and we can give you up the implementation uh and of course I would imagine that we will go through many different iterations of these as we go um but one thing we have and I don't know that we had talked explicitly about was was how we would manage um the versioning or release of individual nodes or like does it probably make sense to have those just be wrapped up in a release of the the suite of nodes in general does that make sense I'm assuming silence's agreement can you can you go into that a little deeper so so like so so theoretically you know as we're working through these someone could say okay I'm making this node and it's its own atomic object that has its own versioning and release schedule and all those things or we could have more of the the share library itself have its own versioning and release that as a node is added you know that would be a new version or node or nodes is are added I see um I think for it to be congruent with node red way of doing things each each would have its own versioning we could do that as a mono repo right we could do a mono repo um we should think about this one though because this one seems like one that we'd get many contributions from different people in the future and they would maybe even want their own recognition for that so um a mono repo might make sense yeah but I guess like the individual repos could I think we can we can we can think through that one but I think they should each have their own versioning issues and whatnot so that would be another action out of then ruining of individual nodes versus uh common share so is the idea that these these custom nodes would like sit outside of the share read repository they would yeah that's what I thought okay yeah but but certainly in terms of like the I would think for the mono repo maybe maybe that is as simple as just being preconfigured to have a certain set of nodes already loaded in well this is this is where I think we need to and Ryan can comment on this but I think um think about how we can have a default uh menu I think in the node red going there's off to the left there's a panel of nodes and I believe Ryan has looked into adding our own category and I think it's based on tagging and so we would tag certain I guess certain repos or use tags or the organization itself the share research organization and load those packages in to the the GUI that way so it doesn't have to come from us specifically but we can tag things marked as share research or we can tag things marked as share in npm which is the um javascript package management system uh as being relevant to share node red and then those things would automatically show up by default in share red um Ryan can you comment on that oh yeah so that's all very doable in uh node red share red um we actually already have it working right now where we can categorize everything within the share category on the left-hand side um and adding a tagging system like you were talking about Jeff would be completely doable how is it done now is it is it hard coded as to what packages go in there into the share section yeah um each individual node with when you create it you specify which category goes into okay so if I was a package developer maintainer on npm is there a way for me to get it into that category or are you are you automatically how are you getting those things in the in the share red right now um here i'm gonna send a picture right now one sec um pretty much when you create the node itself you add the category share and it'll find that if that category is there oh i see automatically very it'll automatically put it there so very good okay so okay good cool so then okay so all right so share red would then just need to include in the package.json whatever nodes that we want to include in that category and then those nodes need to have the category specified as share correct yes okay and if this if they since the category share it would it's completely made up by however many nodes are there so if they entered share whatever name it would make a new category for that so share is the category and it'll add it to it okay so then on the back of end of this it doesn't matter at all how we how we organize the repo so what what okay so then one more question would be uh so that interface we can develop out very easily with how we ship share red share red would have a default set of nodes that would install those nodes would then basically self declare themselves to the share category so now for nodes that we don't include but people want maybe people don't want them included by defaults or we don't want them included by defaults we're we're really giving them some credibility some perhaps indications of oversight or code review or whatever um can we change the default search interface to include things like tags in npm or certain repos or whatnot when you can install from node red i think there's that that goes on the right side i can search and then install nodes is that right yep you can search for any nodes that are share nodes in the search engine that's built into share i mean node red sorry um and we can all have them in a category of share and then you all those with that category would come up when you search for it okay and that's an npm thing then it's built into the node red into node red okay but the data comes from npm i believe so i can double check that for you though okay so that then speaks to having a community standard for for things developed specifically for share red and how people uh the metadata that they add to their packages that they develop right yeah so that sounds to me like we should have a quick write-up of how you create a share red node with an example so there is there is already this ticket share 15 to create that first node um or at least to have an example it doesn't have to be the first node uh so that sounds like we just need an additional task here so let's let's create a let's create a repo under share research called share dash red dash node dash example okay and then we could just have a get hub.io page for that or something i think we can just actually just create a package and people don't be the one that we encourage people to fork as they develop their own packages okay and then just have it have that its own read me or something yep i can have a read me and and all the the training information there but that that's the one that we'll keep up to date as far as how we encourage people to tag their their packages okay so looks like it wants me to create a note first and then convert to an issue so that would be create an example repo issue i can i'll just put this on share red for now and just creating the repo camera and could you do that cam you're nodding can you take that yeah go ahead and do that i keep forgetting i'm muted when i talk let's see can i not assign in this screen okay assign and attach myself as well just to look at the initial set because i even if it's just doing the first fork yeah so so i think yeah i think that sounds good to me for to wait for a cam for you to create that first and then i can work on doing a fork of that that is one more of this in this list of of notes that we have in the agenda here so picking one of those so good and then we can send out the notes of the list and then then it feels much more actionable to me that then we can say let's have someone take one of these okay anything else on this one i think the only other thing i could think of here is uh like timing and maybe table that until the next call date that's currently set for february but we could don't necessarily need to have to wait until february to have our next call um but uh i think is anyone interested in hearing some of the recap of the cni presentation we did i think many folks in the call were actually there uh maybe leo and matt you were not but and harsh but everyone else was there i guess i'm curious like uh what in what context like i know it was a presentation about share research over there and if that presentation or any other um connections and discussions with people over there in that conference have influenced any influencers i don't know that has been a whole lot yet we kind of laid it out uh as an open invitation to try to connect with people organizations that would be interested in contributing but also to let them know there's kind of multiple points in time that that they could engage whether as a development partner new development partner or as an adopter or etc so like we wanted at least like communicate the work that's happening and and then what's what's coming next in the timing there and i think i actually yeah i do actually have this with these were the slides that we went through uh just kind of went through the overall strategy use case Notre Dame talked about their um the community so like monthly calls rampant conditional developers then you know focusing on the core technology and then talked about a bit about things and these are like high-level abstraction diagrams right but like looking at here's a flow and looking at the source etc and we did show like some example flows as well but that was the bulk the bulk of it okay and then the there was the other share related presentation that was around the the NEH the National Endowment for Humanities grant that is around surfacing digital humanities projects better making those more accessible and was were there any strong takeaways from that jeff or judy i think there was this is judy obviously i think there was a great enthusiasm for what um for looking at what can be done with linked funding data project data related to funding so you know the the presentation contained um just great work around um you know distribution of funds by the NEH to institutions by gender of the investigator um just all kinds of interesting things that can be done if there's and then you know um whether there were dois or whether urls resolved at all and just all kinds of it just was a it was it was a super interesting and and i think um people people you know connected to it as um and you know i heard people talking about it afterwards as you know something that um would be just nice to have for any number of funders yeah uh right ryan and cam did a nice job of putting together uh some interesting analyses and graphs um that we showed um maybe we can judy maybe we can link to the uh presentation in in the the notes yeah that's a great idea and we should put it on the share website if it isn't already so yeah maybe write a little item about it or something that that's a great idea and actually along those lines i noticed that the the other presentation cam and ryan it's the permissions are set so that it is not there isn't like a public viewable link to it i'll fix that fix that as well sure okay any questions comments on those well thank you all right so to look at the next call february like like looking at the list of things we have here waiting four weeks to talk again with this group feels too long to me i don't know if others have the same sense it's odd nods um so maybe go ahead uh maybe we can open up one of our developer meetings or publicize one of our developer meetings to the mailing list and and whatnot and then um people could join that if they'd like to in like two weeks yeah that that sounds good so so to give more background so we we've had some smaller discussions just uh myself jeff cam and ryan and harsh as a smaller group uh working through some of this and we've been doing those friday mornings so if we say uh let's see so like january 25th maybe and it's been at 11 a.m eastern so eight eight a.m pacific time uh has been we've been when we've been doing those so that that feels good to me so like if we look to have um to push through these two ones before that i think that that seems like a good objective to have there so like if if we're if we're looking to have a a share a red note example however uh complex it may be or simple it may be have that be done by by two weeks from tomorrow and then we could have that be open is that same reasonable cam ryan yeah or cam that's that's that's your task i guess and i think that's reasonable for me to to look at that as well yeah definitely and we could potentially have more than one example right so great yeah i'm sure we could bump out of you is there anything with the share red runtime environment to think to do harsh i know you had this understand code current no red architecture q still yeah so what i was hoping to do with that is uh probably try taking the current branch of 020 beta that was released today and see uh see what it takes to merge it into our share red fork because i know like some of the work that we talked about today about creating custom notes and so so where that lives in the new code base might change and and i don't know how it will complicate things or it will simplify things um so that's a that's worth a discussion to have sooner rather than later because we do definitely intend to go down that path um so maybe on the share dev call tomorrow um at 11 a.m eastern time maybe we can talk a little bit more about that okay okay and and and honestly i could i could definitely use help from cam ryan to do the merging and make sure we doing the right thing over there if you'd get a chance to try to update the share red to uh was it dot 2o dot 2o beta 3 yeah so if you could try to update that before the call then we could do a little bit of debugging on the call okay sure yeah and then and that seems that's uh this one is share 21 is that basically done then harsh yeah yeah i just wanted to keep it in review so that others get a chance to like add comments or last questions okay but if if there's nothing we can just move it to done both of them actually yeah it definitely sounds like this this is a new task issue yeah yeah so yeah so if you can add that should i like that yeah perfect okay well i think that so so for now we'll keep the so we'll have actually let's put make sure that's in the notes so the next time call so let's add in here some sub bullets here so call a five and there is a different zoom link for that so we can send that out we can send that to the share dev list and the discord channel when ready but do that and then regular can make me call okay all right a weekend adjourn about 10 minutes early here anything else okay um do we want to grab all the links that have been put in the chat oh yeah yes good idea that is not going to be retained looks like it's just the agenda that's been in there so far okay good yeah it's just all that too okay great yep yep yes thank you for calling that out okay thanks all right and as usual we'll get this uh recording pushed up so that that can be available for others to watch later on and i think the november call we didn't do recording for december because uh it was very small numbers um but the november one i think is still pending to get pushed up to youtube so i'll look at both of those good uh i'll look at those tomorrow because it usually takes about three or four hours sometimes for the recordings to come through for this one all right well thank you all for joining i am continually more and more excited as we keep going thank you rick thank you thank you thanks rick thanks all later guys