Formation Task Force Plenary Meeting #7

US/Central
ZOOM

ZOOM

Ian Fisk (Flatiron Institute), Joel Butler (Fermilab)

 Task Force Plenary
     4/4/24
     
     
     [Standing by to begin]
     [Standing by to begin]
     
     >> Ian: Amanda, are we captioning?
     >> Amanda: Yes.
     >> Oh, great.
     >> Ian: Okay. Perfect. Let's give people a few more minutes to get started. And I don't know about -- I had a couple of people who said they couldn't come. But I was expecting Joel, I think. So, we'll see.
     Can people see my screen?
     >> Yes.
     >> Yes.
     >> Ian: Great. Okay. So, let's get started. Welcome. So, today we have sort of -- actually, it says three items -- but only two items to discuss. One is very, very fast, and the other one is probably a bit longer. So, going on to the first item. We got five affirmatives, not counting my own, for a face-to-face meeting. By my calculation, this is 25% of the committee. So, I would propose that we maintain our current format and try to finish our task without a face-to-face meeting. Because it doesn't make sense to organize for five people. We didn't get full response to the Doodle, but I'm counting on if you didn't respond to the Doodle, that was probably a negative response to the face-to-face. I'm proposing no face-to-face. Thank you all for responding.
     And then the item I wanted to discuss today which I would like to switch to the document in a second is a little bit of discussion about objectives. And going -- if anyone looks through the document, they'll see in the version that it's coming together reasonably well. But one of the things that I was noticing as I was going through it, in many cases, the DEI section has the clearest set of objectives and recommendations and actions. And the other -- and many of them are the things in the DEI section tend to be like -- they are very ambitious goals. Including sort of changing entire fields. So, it's unclear exactly how effective this committee will be. But at least the goals are there. And I was wondering, what I wanted to discuss today was the if people thought it was a reasonable approach would be to try to figure out what are the high-level objectives in communications and partnerships? And the technical working groups and career development in the sense of trying to make a parallel structure in those three groups. So, with that in mind, what I wanted to do was to go to the document and just to show what I was talking about. And so, this is the document. I hope I can probably make it big for you can't read that. But they all have their own copies too. But what I meant was that DEI starts with a high-level objective, which is to foster a diverse, equitable, and inclusive environment within the CPSC and the broader computational community in higher energy physics. As part of that objective, there are a few very high level goals, increase diversity, promote equity, enhance inclusion. And there are recommendations for how one might go about that in terms of conducting a survey. Addressing -- working to address systemic barriers. Working to promote remote work. Including environmental considerations. Et cetera. And that what I was noticing as I went through this was that like, for instance, I was thinking that it makes sense to have a similar structure in something like career development. And so, my first question was, do people think this was a reasonable approach?
     >> Liz: Yeah, I think that's fine.
     >> Ian: In which case, then, are there -- is there sort of -- one of the goals of the committee as part of our charge was to essentially do the things -- increase the visibility and prestige of software computing. But is there -- is there a crisp definition of what we would like to do in sort of career development that we would like to put as a high-level objective? And please, Tulika.
     >> Tulika: I have a more fundamental question. What I see here are recommendations which are, you know, let's say pretty focused. So, we are telling CPSC what it should do. But if we become very prescriptive, what is their job going to be? I mean, they're just going to be execute whatever we recommend?
     >> Ian: Yes. Well, actually, I'm not sure. The reason I changed it from actions to recommendations was the idea is to soften our instructions a bit. This is our recommendations to them. They can do what they want. They can choose to ignore the recommendations of the Foundation Task Force if you want. But I sort of get your point also is that we could -- like we could go up a step farther if like to set -- like I think one of our -- the goals of this committee is to sort of establish what we think are important for CPSC to do in terms of like -- so, the DEI section was an example of where things are spelled out. We think these are the things that need to be addressed systemically. But in some sense, career development is another one of those. And where -- if we think there are problems in the field that need to be addressed by someone, we probably -- we should have been identifying what those problems are.
     >> Tulika: Right. I agree with you. I was trying to understand how prescriptive we get. Because, for example, we certainly want to tell CPSC that maybe they should implement an assessment. But here we are telling them they must implement an assessment every five years. I'm just trying to get the balance of, you know, how prescriptive we should be.
     >> Ian: And I think in some places we're being too prescriptive. We should take a step back and say, they should figure out how frequently they need to make these assessments. Things like the establish recognitions and awards. That was a place where people -- that this comes basically from CPAD and where people had sort of strong feelings that there should be such a thing. And so, in this place, we did sort of make recommendations that are, again, a little bit prescriptive, and we should sort of make sure that we're giving the right balance on each one. Giordon. go ahead.
     >> Giordon: Yeah. I'm not quite understanding what you mean in terms of the similar structure between Career Development and the DEI section. If you look at the DEI section, there is a very short, high-level objective for that entire section. But we all kind of have the same structure, don't we? It's just not bolded in the right format. But it's still the same structure. It's just Career Development doesn't have a high-level objective.
     >> Ian: So, I guess what I was suggesting is from my perspective, having a look at the DEI section, there is an objective and goals which are fairly high-level and then recommendations on how to move those. And it was just a question of in the Career Development, if we thought that there was a particularly high-level Career Development phrase that we -- objectives and goals that we could use. And then, for instance, establish recognitions and awards would be sort of some of the steps toward achieving some of those goals. It wasn't a fundamental rewrite of any of these things. It was really a matter of trying to make sure that the format and sort of our like Career Development was an example of one. The other thing was also true of sort of I think facilitate and establish technical working groups. This would be a place where we might to want rephrase this as if this is about training or if this is about knowledge transfer. Then we might want to sort of set that and say there's a high-level goal to do those kinds of activities. And then the working groups are a tool to that end and not necessarily a goal of their own. And then the same in some sense is true of promote strategic links with external entities. If the high level goal is to work on the partnerships between research institutes and committees. Then the sections beneath it become subsections of that. And again, promoting links to external entities is not done on its own, but it's part of information exchange. Ruth? You're muted, I think?
     >> Ruth: yes, sorry. I apparently had to click OK for being recorded first before I could unmute. I just wanted to say I mean, I think there are a lot of very good suggestions that are very concrete. I recognize Tulika's point that it's rather prescriptive. But I also think the solution is to not include really great suggestion. So, I'm wondering if just like changing the verbiage from recommendations to suggestions would make clear that we think they're great ideas, but they're just things for you to work with.
     >> Ian: We could do that. The other thing we could do is put a paragraph farther up in the document about this is a set of initial suggestions/recommendations to the eventual committee. But it will be up to the committee and the membership to -- like this is not -- it's not a strict charge that has to be like -- this isn't a set of instructions. This is a set of recommendations or suggestions. Or however we want to phrase it. But I think that we could -- someplace in the document, we should be clear that like this is not -- we're not making bylaws here. We're making recommendations. Jan.
     >> Jan: So, when we give these objectives, I think it would be helpful to also suggest some sort of benchmarks. Like -- what do we mean -- like, how -- how can the Task Force, how can the panel like check itself? That it actually does what we suggest or, you know, that it actually is aligned with what we suggest?
     >> Ian: Okay.
     >> Jan: This is a bit vague because I just thought of it. I don't have any specific examples. But something quantitative that can have, you know, this is something -- here is why we think this is a good idea and how we can actually evaluate that this makes sense. Yeah, I don't know. It's a bit vague. We need examples.
     >> Ian: For instance, if you look at the DEI example, there's the proposal to have a survey to see things are changing. And I think the same might be true of career development, where if there are metrics that we want to use. No matter what is happens to be. Number of people faculty members whose primary consideration is software. Those, I think, that one can have those kind of surveys and to assess the -- I think it's part of my goal in this is that we should have goals and objectives in each of these sections where sort of as the -- this committee is proposing, these are the kinds of things we would like to see evolving in the field. There's some high-level goals about that. And make sense, when you define those things, to see how you're doing on shaping those evolutions.
     >> Jan: Right.
     >> Ian: Whether that's -- it could be career development, it could be number of training sessions. I think any number of -- I think all of these things are tied together. But I do -- I agree in the same way that I think there's a real value in the DEI section of saying this is how the field is evolving, I think that we should also -- it doesn't -- I agree, it doesn't really make sense to sort of say that you want to do something -- without verifying that you're actually making -- doing something.
     >> Jan: Yes. And I think that thinking about how to quantify this from the start also kind of prevents us from making armchair recommendations.
     >> Ian
     >> Yeah. Giordon.
     >> Giordon: I have a question and a comment. And the question. It was brought up the differences between recommendations and suggestions here. Is that distinction because of something that's specific to this Task Force? Or is that more trying to prevent something from the future where people get into an argument about the document we are making because we said "Recommendation" versus "Suggestion"?
     >> Ian: I... I think -- and Ruth can comment -- I believe the -- it was a matter of trying to -- choosing a softer word. We started with "Actions." And actions sort of sounds like instructions. And recommendations sort of sounds like guidance, and suggestion is maybe a little softer even than that. But in some sense it was -- I think the idea was to make sure that the eventual final committee has the flex -- like has two things. Has some -- our goals as to what we thought was the most important thing for the committee to be working on. And we'd defined sort of the sections of that. And then the other was to make it clear that, especially with the evolution of time, that people shouldn't feel this is -- that they're sort of -- like bound, constrained by these recommendations. So, for instance, we said task forces, we said there shouldn't be more than five. Well, if the committee decide well, there should never be more than four. No one should be going, we're not writing the constitution. There won't be no one to sort of check them later. Ruth, go ahead.
     >> Ruth: Recommendations at least for me is a little bit more of a loaded term.
     >> Ian: Okay.
     >> Ruth: Coming from someone who has been reviewed many times are things that you are really, really, really strongly encouraged to do. And if you come back to a future review and you did not do some of the recommendations, you need to explain and articulate very much why you didn't do them. And so, I think it's like this loaded word for some people who are used to like that interpretation of recommendations? And I guess the point is we don't want to make it sound like if you don't do all of these things, like, I don't know. That's my take on it.
     >> That's a -- I think since we're dealing with a community of people who frequently gets reviewed, I think we should -- it should be sensitive to not use the language that causes them nightmares. So, yeah. I think suggestions is probably a good -- is as good a term as any. I can do global search and replace.
     >> Giordon: So, then, I think based on that, you know, if we're talking about the structure here, perhaps it makes sense to go from the order of what we would consider strict requirements to suggestions. So, for example, I'm just looking at what you're sewing on the screen. Obviously, I think, you know, saying something like 3.2 would be a strict requirement. You know? You were saying, this is A recommendation. And then the question then is, you know, how do you approach the recommendation? And then there are some suggestions from this Task Force which could be used. We could say 3.2 is a recommendation or requirement. Or something stronger and then recommendation to suggestions as ways or possibilities for being able to, for example, promote strategic link with external entities, how would you do that? And these are some of the ways you would do that.
     >> Ian: Okay. I think that's a good modification. I was thinking of if possible to pull sort of the objectives farther up in each of the sections. So, for instance, because I think some of these are -- like I think an objective -- this is -- it's not a recommendation. It's that we are encouraging facilitate strategic partnerships with research institutions, and other scientific communities. That I think was part of our charge and it's a reasonable -- so, I think some of the objectives will be like those will not read as either recommendations or suggestions. They will simply read as goals for the committee. And they should be, I hope, not especially controversial in terms of like why you would want to do this. But then I think going farther down, as you get into recommendations and suggestions then it becomes I think a lot -- there's -- some of those will be -- there may be multiple solutions to problems and multiple ways of approaching it. Tulika, your hand was up?
     >> Tulika: Giordon said most of what I wanted to say. But I also wanted to include, Ian, I think one of your suggestions that somehow at the very top of the document, I think there needs to be an introductory paragraph which actually lays this out and the difference between a suggestion and a recommendation or whatever we end up calling it. I think the two together will work well.
     >> Ian: Okay. And I would like to introduce a third concept. I would like to introduce an objective, which is sort of a high-level goal. And I hope we can all agree that these are laudable goals that people should be working toward. And then there may be recommendations which are things where we think that -- we feel strongly that the committee should eventually follow these things. These are the ones less prescriptive and sort of more high-level. And then there would be suggestions where there may be other proposed solutions that people want to work. But these were the ones that we came up with for the purposes of this document. Okay? Other comments here? All right. So, what I was hoping to do today sort of with the people who are here is actually to try to outline a little bit sort of what we think the highest level important objectives are in each of these sections.
     And maybe the thing to start with would be start with career development. Because I think it's probably the one that's clearest. There's a lot of guidance in the original charge about essentially this first objective, which is to increase the visibility and prestige of software and computing contributions within HEP. Which in many ways guides the recruitment, retention and training. And increasing the number of stable positions within universities. All of these are essentially tied, I think, I would argue, to the same general idea of increasing sort of the perceived value of software and computing within the HEP scientific domain. And so, would like -- I would propose that we start with that as the highest level objective in career development. How do people feel about that?
     >> Liz: I like your suggestion. Because the way it reads now, it's a little bit like you don't get the big picture when you first start out with bullets. Let's just say that.
     >> Ian: What I wanted and what I was hoping to convey with a couple of objectives is sort of what we think the biggest problem in career development is. And if people think it's something else, say that or write that down or include that as a point. But going through this, a lot of these sort of come from the idea that software and computing is seen as not integral enough into the scientific process. And so, people's contributions are not valued as much. Or that people have to do other kinds of things to be seen as valued. And so, if that's the career issue that we're trying to solve, we should start with that.
     >> Liz: Yeah.
     >> Ian: And there's training and there's structural challenges. And increasing like -- there's all sorts of things in here. But, Ruth, go ahead.
     >> Ruth: I guess when I look at this I see "Promote career development," like as a big overarching theme. And I sort of see these structural changes and this enhancing training and everything really as like things that like promote career development. I'm to the saying that's how we want to organize it, but certainly in my head --
     >> Ian: Okay.
     >> Ruth: Like I think they do that.
     >> Ian: So --
     >> Ruth: Never mind.
     >> Ian: Go ahead.
     >> Ruth: I could imagine seeing that the objective is like promote career development. The recommendations are address structural changes, enhance education and training and some like suggestions we have on how one might go about it are blah.
     >> Ian: Right. And one step higher which is: What does "Promote to career development" mean in this case?
     >> Ruth: Which is a good question.
     >> Ian: Because in my argument about what the objective was, "promote career development" effectively meant allowing -- the shortest version -- allowing people to get faculty jobs because they contributed in software and computing. Which is like a simplification, but changing the way we think about software and computing so that it is more key to the whole -- the core of the science, I guess. So, that when people go for career advancement, that software in computing is enough. That they don't have to -- that's enough to advance. But I'm not especially -- I'm not being -- feeling especially eloquent today.
     >> Ruth: No, I agree. I think it's, you know, convince the community that this is like a worthy like, you know, scientific career path. Not --
     >> Ian: Yeah, it is -- keeping back to the concept of if it's being central to the science. In the same ways that lots of other detect or development is central to the science. But I think going back to your original concept, I think that promote career development through the -- and I think we can say "Promote career development through..." -- yeah. We'll figure it out.
     >> Ruth: Anyway.
     >> Liz: I mean, promote career development could be a higher level goal than, you know, enhanced training and education. I mean, you obviously need enhanced training and education in order to promote careers, right? So, some of these I see as more major bullets than others. I guess that's what I want to say.
     >> Ian: Yeah. I think with the pro career development -- I guess going back to the what is the problem we're trying to solve? The problem I think we're trying to solve is that not everyone is -- not everyone who focuses in this area is able -- has the same opportunities for staying in the field in an academic track. The parts of science and so, we need to --
     >> Liz: I wouldn't even -- sorry to talk over you. But I wouldn't even restrict it to academic track. You know? Like I'm struggling to get my generator level 2s even like lab jobs and things like that, right? So, it's to stay in the field, period.
     >> Ian: Okay.
     >> Liz: But I would agree it would certainly help. There are many more universities in the world than there are laboratories.
     >> Ruth: I mean, to amplify that, I think it's also to convince the community that we need physicists who are good with computers or -- I mean, we need people that actually have the physics background too that like computational physicists are not replaceable by software engineers or other types of people. Like I just feel like it's in some sense promoting the discipline as a whole.
     >> Liz: Yeah.
     >> Ian: Yeah, I like the promoting the discipline as a -- I think that's a crisp way of phrasing what we're trying to do. All right. Are there any other comments about that? What I will try to do is I will -- I'm gonna try to sort of go through the document over the next couple of days and introduce these sort of structural changes without making a lot of other modifications to the things that are there. And then we'll see how... let's see...
     But just as an example, if we do this in career development, then establishing recognition and awards is a tool toward overall goal. It wouldn't be the first bullet. I think that probably makes sense, I think.
     >> Liz: Yes, I agree with that.
     >> Ruth: But I think we could have a recommendation be establish recognition and awards.
     >> Ian: We should.
     >> Ruth: Right? And details about how to implement that are suggestion level.
     >> Ian: Exactly. Yeah. I think that's a -- and then also going back to Tulika's point. If we sort of spell out what we need by each of these terms, then it's also -- it also makes it very clear that we think it's important to establish a recognition award because it's -- that has been a successful technique used in the past and we would consider it to be not as successful to the committee if we didn't do that. But exactly how they did it is up to them, or we have suggestions about how you might. This one. Facilitate and Establish Technical Working Groups. I guess there's -- I think there's a lot of useful recommendations in this part of the document. But I want to establish what is the problem we're trying to solve? And what do we think this Committee can do?
     And so, maybe that like the idea -- if we want to stay establish a forum to sort of promote new ideas or like -- I think there's a number of things that could be done as the high-level objective. Even the high-level objective, ensuring that high energy physics computing, it remains on the forefront of development. Like I think there are a number of things that we can put in here as the objective. And the technical working groups are a tool to do that. They're not an end result of their own.
     >> Liz: Yeah, I think there are also a few other bullets in here that could be raised to a high level objective. Like, for instance, the avoid duplication of efforts, you know? Random things pop up. Like the -- we should make Jan work on GPUs, right? Then we hear people are funding an effort in that the UK. And people funding an effort on that in Oakridge. And before the HSF, they weren't even talking to each other. And it's been really beneficial that they talk to each other. And so, I think that one could be -- it's not so much -- duplication sounds like we're being pejorative. But it's more like facilitate cooperation on common technical goals.
     >> Ruth: Yes.
     >> Ian: And do a document search before we start.
     >> Liz: That's right. Maybe the funding agencies should do that too?
     >> Jan: Well, so, on the documentation side, I think things start a lot of the time at the same time and in parallel and then percolate to the visibility. And then you realize these guys have been working on the same thing for a year.
     >> Liz: Yeah.
     >> Jan: I think the existence of that point of contact, I think that will already help. Because then you have, you know, people talk to each other a long time before they start writing documentation.
     >> Ian: Yeah, I'm wondering in this particular section in many ways I think these technical working groups, people are gonna have to be very careful because they are likely to be -- a lot of these things are going on. And this group can help facilitate discussions between groups. And that's a very valuable contribution. For things that are brand new-- yeah. I don't know how -- I'm not sure how many times we're going to be duplicating effort. But...
     And --
     >> Jan: I don't think we should take this to the extreme, right? This is to some small degree duplication is good. You want some overlap. If everything is diagonalize, then everybody is different.
     >> Liz: I wasn't suggesting that. These two groups went in different directions. But it helped explore the phase space of possible solutions. And, you know, helped each other come up with pros and cons of different approaches.
     >> Ian: And I guess one thing I wanted to point out. We do have sort of two sections. One is section three which is enhance communications and partnerships. Which is supposed to make sure that groups are working together and that -- whether that's labs or universities or other external organizations. And then there was sort of a more focused technical working groups that were sort of short-term. And also, the idea behind them was that they should focus on actionable outcomes. And be -- and so, I think we -- unless people -- I think we should -- we believe probably try to keep them apart, I think.
     >> Liz: When I first read this, I was thinking maybe we should put them together. But if you want to keep them apart.
     >> Ian: I guess it depends -- when we had the first discussions about this, people wanted the technical working groups to be quite technical and short and fixed-term and focused. Well, the communication ones tended to be a bit longer term and a bit more diffuse.
     >> Liz: Okay.
     >> Ian: We need to be working with the technical working group, if we want these at all, figure out what the overall objective is.
     >> Liz: Yeah, we need to be more crisp about the -- the first sentence, technical working groups are a powerful tool to facilitate communication when you have just finished a communication towers. I kind of get it when you said the two words what the difference.
     >> Ian: We need to make that clear with the document too. Ruth --
     >> Jan: Sorry, Ruth, you go first. You raised your hand.
     >> Ruth: It's fine, it's fine. I guess my question is more sort of the at what level is the facilitate the establishment of technical working groups? Because the way it's organized now, it makes me think that's a fundamental objective. Whereas it seems like it's really a recommendation.
     >> Ian: Right. I sort of --
     >> Ruth: And so, I guess to me like maybe like the structure will make more sense if it's in something more overarching. And then this is a recommendation. And then there's suggestions about how to implement the task -- technical working groups more concretely.
     >> Ian: I agree. And maybe this will also then satisfy Liz's comment. Which is that if we folded this under communications and partnerships as a technical arm of that where there was a recommendation for -- if you needed specific technical working groups to work on topics that this is where they would be founded. And try to distinguish them from sort of partner -- like technical working groups and partnerships are not the same. And so, what I think we could put -- maybe by folding them underneath the technical partnership section, that would be clear.
     >> Ruth: It occurs to me if we make the recommendation establishing technical working groups and task forces as-needed.
     Like if we just add the "As-needed," it makes it clear we're not talking about standing committees and long-term things. It's more of a this is a flexible tool you have for dealing with things.
     >> Ian: Yeah, Joel.
     >> Joel: Apologies for being late. I was doing my EPS duties up until 10 minutes ago. So, I may be a little bit out of context. But, you know, at the beginning of our discussions, we kind of ruled out having a deep-standing organization, you know, with an org chart and a lot of boxology. That was a decision that in other words it St. -- couldn't be a fore gone conclusion that that was the best thing. You know, CPAD, for example, which we sometimes take inspiration from is elaborating more and more detailed structure. We had a structure in computing at Snowmass which was well thought out, but probably more limited than -- in scope than this group would want. So, I think we have to have some structure beyond the very superficial structure that we had if we wanted to be taken seriously. So, the idea of basically having technical working groups which could be brief ad hoc groups or could be longer standing groups, but would not be forever groups seem to be a good idea. So, you know, what we could say here instead if we wanted to retain section 4 and discuss this which I think would be a good thing. Roll with technical working groups or something like that. So, it doesn't sound like a recommendation quite as much.
     >> Ian: Okay.
     >> Joel: And then flesh that out and add a recommendation and look into what we think an initial set of groups would be as one of the first, you know, first organizations. And we put something into always review what we have so we don't build, you know, potentially a structure where we just graft more and more on to the working groups. I think that would be a good thing. And I wanted to say one other thing which was when you were talking about avoid duplication of effort. Somebody -- I can't remember who, may have been Liz -- gave a much better formulation. I think Ian did too. We shouldn't make that a negative. We shouldn't tell people what to avoid. We should tell them what positive things they should do that captures the things that you said. Which I think were that it is a way of, you know, kind of, you know, paying attention to what other people were doing and aligning with them when it makes sense. Something -- that's not very well-stated. But something somebody said. Something that was very appropriate. And I'm not in a position where I could easily write it down on the recording, presumably. But I thought that a more positive way of saying that.
     Because it does look like you should never check anybody's work. You should never try an alternative to improve something if you read that in an extreme way, avoid duplication of effort. And somebody may always invoke that against your undertaking and improvement efforts, for example. So, I think it's a great idea and it's appropriate idea. It just needs to be re-formulated.
     >> Ruth: I thought Liz had suggested something like promote and facilitate collaboration and cooperation or something. Like the positive spin.
     >> Liz: Yeah.
     >> Joel: Yeah, but I think the word alignment -- somehow to say that we should try to align things where it looks like two people are going more or less in the same direction and more or less the same way. We have to really encourage them not to just communicate, but to actually --
     >> Liz: Collaborate.
     >> Joel: Collaborate, yeah.
     >> Ruth: I would think cooperation and collaboration. Cooperation is potentially lots of different ways of doing it. Because I don't think people should always join efforts even if they're doing the same thing. Because sometimes you learn things along the way.
     >> Liz: Yeah, that feeds into a comment that I was going to make about this was that, you know, there's lots of things that go into scientific computing. And some of them are closer to the scientific investigation and, you know, the part of the field that you want to have lots of different research directions. There are other parts like workload management systems that we as a field kind of suffer because there is so many of them. You know? That do exactly the same thing. So -- and I don't know how to -- to discourage -- like I don't want to be pejorative, right? I don't know how to, you know, describe one of them as positive and another one as maybe wasteful. To put it bluntly.
     >> Ian: Two things. Joel, just to catch you up. This discussion started with me observing the DEI section had the clearest high-level objective and how to solve, approaches for how to solve it. And I was approaching that all of the sections have a similar structure where there is sort of a problem statement of an objective of the thing that we're trying to fix and then goals and recommendations. And so, Career Development, we discussed a little bit. And then we came here into the Facilitating and establishing Technical Working Groups. I hope we can find a way to keep this section and say: Our objective is -- this is the objective of this section of this activity. And then some recommendations of making these groups.
     >> Joel: Yep. It sounds like a very good goal. Because it helps the brain organize across sections, I think. Right.
     >> Ian: Go ahead.
     >> Joel: Go ahead, sorry.
     >> Ian: And the same is true here where Communications and Partnerships. The like -- this one -- so, I think the objective is to enhance partnerships and the species exchange. And then all of these other sections in terms of promoting strategic links with external entities, communications, are all elements that have. But the high-level goal is really information is expertise and information exchange. Partnership. And these sections are sort of fundamentally different from the membership and governance section which I think we'll discuss next time. Because like this section is really our sort of instructions for how we think the committee should be born. The other sections really are areas in the field that we're trying to evolve.
     >> Joel: So, right. I mean, one is kind of a framework for governance and the other is really what we think the committee should turn -- the panel should turn its attention to and try to achieve when it gets started, right?
     >> Ian: Yep.
     >> Joel: Those things will change over time in some sense. The objectives may not, but the things under them may well, right?
     >> Ian: Right.
     >> Joel: So...
     >> Ian: And the topics, technical working groups will change all of the time. But the idea that there are new ideas in the field and we need ways to expose those to people and figure out if they are appropriate for adoption by -- by high energy physics. I think those kind of things can be put as sort of goals of exposing new technologies and establishing -- like making recommendations for research directions. Theoretically, one of the outcomes of this could be recommendations to the funding agencies in terms of what things are likely to get additional support or should get additional support. And that's a -- it could be an outcome of technical working groups is that -- that would be fixed duration and not necessarily solve a particular technical problem. But make assessment of its potential value. Jan?
     >> Jan: Yeah, thanks. I just wanted to pick up what you said about the communication and partnership section. So, you suggested that the key thing here is enhanced partnerships for expertise exchange and everything else is subsections of this. I think 3.2 is definitely worth its own level there. The links with external entities. And I'm thinking about specifically the funding agencies and industry. I think that deserves its own --
     >> Ian: Okay.
     >> Jan: Top-level heading.
     >> Ian: All right. I will put that one of the -- when we re-do the objective level section, include both of those.
     >> Jan: I agree with the rest is kind of subset of expertise exchange. But yeah. I think the --
     >> Ian: And clearly --
     >> Jan: External entities are important.
     >> Ian: Yearly meeting is something that is important.
     >> Jan: Yeah.
     >> Ian: All right. Okay. So, we sort of -- in this section -- so, for this section, for section 3, we've proposed that we will make an enhanced partnership and information expertise exchange and promoting strategic links in the community both within and without of the community as our high-level objectives in section 3. In section 4, I think I'm gonna try to make -- to phrase one that's basically based on a forum for assessing of new ideas or something along those lines or like -- like evaluating innovative new research directions or something. That are -- and then for career development, we're gonna talk about that is the high-level objective is basically sort of how we -- how we evolve and develop the careers people -- how do we like basically how do we keep people in the field. How do we -- how do they like promote advancement? Ruth said it for a better than I did and we wrote it down so we will be using that.
     Liz.
     >> Liz: Yeah. Just one other comment about 3 and 4. That is that -- so, let me give an example and ask where you think it's more like. So, a topical group on meeting the challenges of heterogeneous computing hardwares that are becoming available. And we as a science field have to take advantage of. That's not something short-term. So, I don't know if that would be a working group or what would it be? I guess is my question. Or maybe it's a silly question. I don't know.
     >> Ian: It's not a silly question. I guess actually it's not a silly question at all. It sort of goes to the heart of what this group is expected to do. So, I think -- so, in some sense, this -- if we say "Communications and partnerships are supposed to establish connections between -- enhance the communication between the HEP community, "then in theory this group might sort of convene workshops or training or forum on this particular area that might like that could last a short or long period of time.
     >> Liz: It would be hard for me to pin down a time that sort of forum would be useful or not useful for, you know?
     >> Ian: But I guess the... but there are some things that I guess I'm -- I'm just going to as to the past. The migration to C++. Like had this form existed at the time of the migration to C++, what could it have done to be useful? There could have been a task force to look at the generic performance of C++ applications and the amount in the field and outside. And the feasibility -- make an estimate for the amount of work for people to do. You could imagine a that sort of fixed-focus task force is what we could do. And the same, what would it take for us to switch to Julia, for example?
     >> Liz: Yeah.
     >> Ian: That's something a task force could do. But that's different from sort of how do we -- and at the same time the same thing could be true for heterogeneous applications like GPU. You could imagine a task force this is the amount of technical expertise we have, and this is the amount of time it takes a person to do this -- and have a task force report saying this is important. But in terms of how someone moves their software, that's a community-wide effort and beyond us. That's a level where the funding agencies have to get involved and have a collaboration that has got some resources behind it. It should be a collaboration from the group saying we could do that. But that's sort of beyond our scope.
     >> Liz: Okay.
     >> Ian: There was a hand from Joel and then Giordon. Joel.
     >> Joel: Yeah, I don't have anything very profound to say except that, you know, this was an attempt to suggest that this can't -- the mission of this group cannot be carried out simply by the rather thin panel -- which is, you know, gonna be 15 people. They can't cover everything. So, you know, the idea behind these task forces or working groups are to have them relatively, you know, specifically charged and then to see how they work and to review them every once in a while which I think we'll put in there. We should probably put in there. To see if they continue to be effective. Now, you know, we have many examples in computing where things that were put in at fixed points of time where there seem to be emergencies. 25 years later are still -- still extant. Liz -- somewhere in this there's a mention of epics, right? That's one that came along at a specific moment where we -- a lot of people were converting to UNIX. And help was needed. But it's continued, I gather, to be very useful all of these years. So, one of our standing -- one of our task forces could become, you know, long-lived like that if the general problem was still there. But I don't think we should assume that that will be the case. And we should make sure that we review say every three years. All of our -- all of the task forces that have been generated to see whether there's still useful. And then this gets around the idea that we need to have an elaborate boxology because computing changes so fast that, you know, even if the boxes had the same title, they could be the completely different things over time. Anyway, that's just was what I was thinking about this.
     >> Ian: I think it's valuable to keep this exchange because it gives the committee the flexibility to expand and to make Subcommittees, essentially. Giordon, you had your hand up.
     >> Giordon: Yeah, I did. But it was slightly unrelated to this discussion. I'll just wait for it to wrap up a little bit.
     >> Ian: Okay. That's actually -- given that we're at the top of the hour, just to wrap this part of the discussion up. I will over the -- I will try to implement these changes in the document. People should at this point feel free to edit any section that they want, and as they see things coming together, they should get the fix and overall you should have editing privileges. Which brings us to the other business section of the meeting. Giordon. Take it away.
     >> Giordon: Oh, yeah, sure. I just made a quick change to the document kind of thinking about what everybody has been saying today. So, if you scroll up, you might also have to refresh or recompile. I added a subsection for 1.3. So, I was just thinking about sort of that there is -- I added this 1.3 to kind of note down what we're trying to expect for each of these sections below. The other thing that I changed is that instead of doing 1, 2, 3, 4 of the activities, which you've labeled are now lettered by A, B, C, D, and E. Within each of those activities they will be numbered with the subsection so that way you can say that anything with a number like, say, B.3 or C.4 are the actuals. I'm going with the treatments -- okay. This is -- this is terrible. But I'm thinking about this in term was a video game. Where you kind verify achievements you need to get. Like -- so, the idea is that any -- at least in my mind -- anything that's a subsection here are things that you do need to achieve as part of that activity in order to complete the activity entirely. You need to do something about and gain each of those achievements essentially. And then within those achievements you have suggestions or ways of completing that achievement. And that's kind of how I'm organizing it. But we can still complete changes. I just wanted to add in the section 1.3 just to kind of put it all in one place. And we can leave it there for people to actually be able to read and understand what's expected.
     >> Ian: I'm glad, yeah, thank you for the section 1.3. I guess -- it's an interesting concept. And I think for -- in my -- achievement and the objective are similar phrasing, I think. So, I'm actually happy with either. Do people have a strong opinion? You are welcome to -- the whole thing. Joel?
     >> Joel: I didn't have anything to say. I think --
     >> Ian: Okay. Okay. Well, I think what we should try to do is we should like -- I'm happy to sort of to try to use the phrasing. And see how it goes. And we'll -- all right. And that was the -- let's see... the only other thing I wanted to do today was to ask people since there weren't a lot of us who were writing in the DEI section, there was a number of volunteer auditors, but only volunteer members were Maria and myself. I went through and we'll go through and change these -- for the modifications, if we were going to go through the new naming convention. But basically this was sort of the idea. Like there was a high-level objective or achievement and then the goals and recommendations. And if people could read it and make corrections that would be great. Because as I say, there weren't that many of us participating in this section. I've also -- the original -- there was a number of sort of notes from the meeting that people who had contributed. I tried to make sure that those are reflected in the text. If I missed any, please put them back in. They didn't get deleted. They simply got put as comments in the text. If you go and look, you will see them. They're just not in the document. I think this is a place where we're ready to have people do some editing. I did clean it up a little bit, there were a couple places where we violated the law. I thought we should probably not do that. So, we were trying to find resources for people under general sanction. That was I think part of -- one of our -- one of our discussions was about how to sort of get support for people regardless of nationality. And somehow as part of the transcription of the notes, what ended up there being -- there was a comment about finding resources for people under general sanction. Which probably would be like -- we do sort of make it a little vaguer than it was. So, I've done that.
     So, all right. So, I would encourage -- someone -- the chat window is up. Oh. Tulika had to leave. okay. So, why don't we -- I will make some edits and we will make an Indico edit for this meeting. And put the transcript for that there. Apologies for that not happening before. And we will meet again in two weeks on April 18th. And I would encourage people to work on the document in the meantime.
     >> Giordon: Yeah, the only thing I'll mention April 18th I may or may not have jury duty. So, I don't know if I'll be able to make it. But we'll see.
     >> Ian: Okay. I believe this meeting is an excellent excuse for getting out of jury duty, by the way.
     All right. Okay. Thank you and we'll see you all next time.
     >> Liz: Thanks, Ian.
     >> Bye.
     >> Bye, bye.

 

There are minutes attached to this event. Show them.
    • 1
      Introduction and discussion
      Speaker: Ian Fisk (Flatiron Institute)