let's talk about Governance
Greeting yt developers, First, I want to congratulate everyone here on the successful release of yt-3.0. This was a massive effort on the part of so many and a true testament to the strength of this team. At the time of writing this, there are 78 members of the yt-dev mailing list. As someone who does most of their work in very small collaborations, this amazes me and make me very proud. In case you're wondering, the yt-users list has 268 members. As a project, yt has a significant amount of infrastructure: code review with pull requests, issue tracking, automated testing, emails lists, an IRC channel, enhancement proposals, workshops. All of this is evidence of our legitimacy as a Real Thing. However, one big missing piece is a system of governance. I don't know exactly what this means, but I have some ideas, which I will share below. What I want to do right now is to start a discussion that will, hopefully, include as many people as possible on this list. For me, governance means (roughly) the following: - a set of procedures in writing for how various things are to be done, such as acceptance of pull requests, releases, designating developers as core contributors, etc. - a governing body to make decisions and help guide the project. This accomplishes a number of things, which as a project I think we need, such as: - overall stability of the project. - providing a system for conflict resolution. - maintaining the spirit of yt as a team effort. - providing a way for active contributors to get credit for their contribution in the form of official recognition. So, these are my initial thoughts, but I really think this deserves a thorough discussion with as many people participating as possible. Please, think about what governance means to you, whether we need it, what it should be, and what we might get out of it, and share your thoughts over the next few days. I look forward to this discussion. Britton
On Tue, Aug 12, 2014 at 2:11 PM, Britton Smith
Greeting yt developers,
First, I want to congratulate everyone here on the successful release of yt-3.0. This was a massive effort on the part of so many and a true testament to the strength of this team.
At the time of writing this, there are 78 members of the yt-dev mailing list. As someone who does most of their work in very small collaborations, this amazes me and make me very proud. In case you're wondering, the yt-users list has 268 members.
As a project, yt has a significant amount of infrastructure: code review with pull requests, issue tracking, automated testing, emails lists, an IRC channel, enhancement proposals, workshops. All of this is evidence of our legitimacy as a Real Thing. However, one big missing piece is a system of governance. I don't know exactly what this means, but I have some ideas, which I will share below. What I want to do right now is to start a discussion that will, hopefully, include as many people as possible on this list.
For me, governance means (roughly) the following:
- a set of procedures in writing for how various things are to be done, such as acceptance of pull requests, releases, designating developers as core contributors, etc.
+1 on formalizing our practices for all of this. This should be a YTEP.
- a governing body to make decisions and help guide the project.
Can you expand a bit more what you have in mind for what this governing body could be? In the past we've made decisions in the open and democratically, usually by a preponderance of people giving a +1 on something. I can certainly see why having something like this would be useful for conflict resolution but I don't really like the idea of having leadership or a BDFL. Perhaps this should instead by an ombudsman whose task is to guide conflict resolution discussions?
From a purely legal perspective, NumFocus provides an "official" framework we can operate under. According to the NumFocus website, we're an "associated project", although it's not clear to me what the distinction between the "associated", "core", and "other" projects is with respect to NumFocus.
This accomplishes a number of things, which as a project I think we need, such as:
- overall stability of the project.
- providing a system for conflict resolution.
- maintaining the spirit of yt as a team effort.
- providing a way for active contributors to get credit for their contribution in the form of official recognition.
So, these are my initial thoughts, but I really think this deserves a thorough discussion with as many people participating as possible. Please, think about what governance means to you, whether we need it, what it should be, and what we might get out of it, and share your thoughts over the next few days. I look forward to this discussion.
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Britton,
I think your suggestion is great. Like Nathan, I agree that a ytep should
potentially be a good place to codify the procedures associated with pull
requests, releases, making contributions, etc. Having them written down is
key, so there aren't any misunderstandings about what one developer thinks
is the standard versus another developer.
As far as a governing body, I guess I don't know what you suggest. You
mean like 3-5 people who "direct" the overall direction of the code and
features to tackle in the not-so-distant future and deal with some of the
other issues you raise like conflict resolution, stability, and credit? I
could potentially be in favor of this depending on the details.
I do think that it would be great to have a mechanism in place to recognize
major contributors to the yt effort, although I'm not sure what that is.
Previously we had some sort of informal list of core developers, but
that's basically just self-selected and doesn't really make it outside of
this email list (if it even makes it here). The time and effort that many
of us put into yt is substantial and there isn't much official recognition
of this, so I'm definitely in favor of creating something to ameliorate
this problem, but I don't really know what.
So in summary, I'm in favor of moving this discussion forward, but I don't
have any mind-bending suggestions at this point.
Cameron
On Tue, Aug 12, 2014 at 2:11 PM, Britton Smith
Greeting yt developers,
First, I want to congratulate everyone here on the successful release of yt-3.0. This was a massive effort on the part of so many and a true testament to the strength of this team.
At the time of writing this, there are 78 members of the yt-dev mailing list. As someone who does most of their work in very small collaborations, this amazes me and make me very proud. In case you're wondering, the yt-users list has 268 members.
As a project, yt has a significant amount of infrastructure: code review with pull requests, issue tracking, automated testing, emails lists, an IRC channel, enhancement proposals, workshops. All of this is evidence of our legitimacy as a Real Thing. However, one big missing piece is a system of governance. I don't know exactly what this means, but I have some ideas, which I will share below. What I want to do right now is to start a discussion that will, hopefully, include as many people as possible on this list.
For me, governance means (roughly) the following:
- a set of procedures in writing for how various things are to be done, such as acceptance of pull requests, releases, designating developers as core contributors, etc.
- a governing body to make decisions and help guide the project.
This accomplishes a number of things, which as a project I think we need, such as:
- overall stability of the project.
- providing a system for conflict resolution.
- maintaining the spirit of yt as a team effort.
- providing a way for active contributors to get credit for their contribution in the form of official recognition.
So, these are my initial thoughts, but I really think this deserves a thorough discussion with as many people participating as possible. Please, think about what governance means to you, whether we need it, what it should be, and what we might get out of it, and share your thoughts over the next few days. I look forward to this discussion.
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
Hi Britton,
Thanks for bringing this up -- it's a tough topic, but also I think
really important. At the WSSSPE conference last year, a paper was
submitted talking about the Apache model:
http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug...
which talks about a lot of related topics. Apache does some
interesting things. They use the word "meritocracy" which I am rather
-1 on using (see, for instance,
http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun...
) but I do think there is something to be said for a large part of
their methods of organization.
Like you, I think we are overdue. I would like to point out that, for
all intents and purposes, you are *already* the ombudsman for the yt
community. I don't think you're proposing we have a committee that
bosses everyone around, but rather one that enables a larger number of
people to have a say, particularly because yt has become embedded in
many of our scientific workflows and it touches a lot of research
activities now. I like the idea of members. I like the idea of a
project management committee, but it's not clear to me how that would
work, or which decisions we have made recently that they would weigh
in on. I also really like the idea of having "code liasons" to
different data platforms and/or communities, and the idea of having
people who are responsible for many different areas of the code and
codifying that in some way is quite attractive to me.
For what it's worth, a few weeks ago I gave a presentation on my
"vision" for the future of yt (http://goo.gl/JKt6MA). The thing is,
while I gave this presentation, it's just *my* vision -- it is not
necessarily anyone else's vision. And I think it's time we have some
method of taking into account a diverse set of opinions for what we as
a community can emphasize, how we resolve conflicts, and so on and so
forth.
Again, thanks for bringing this up. We need to have this conversation.
-Matt
On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith
Greeting yt developers,
First, I want to congratulate everyone here on the successful release of yt-3.0. This was a massive effort on the part of so many and a true testament to the strength of this team.
At the time of writing this, there are 78 members of the yt-dev mailing list. As someone who does most of their work in very small collaborations, this amazes me and make me very proud. In case you're wondering, the yt-users list has 268 members.
As a project, yt has a significant amount of infrastructure: code review with pull requests, issue tracking, automated testing, emails lists, an IRC channel, enhancement proposals, workshops. All of this is evidence of our legitimacy as a Real Thing. However, one big missing piece is a system of governance. I don't know exactly what this means, but I have some ideas, which I will share below. What I want to do right now is to start a discussion that will, hopefully, include as many people as possible on this list.
For me, governance means (roughly) the following:
- a set of procedures in writing for how various things are to be done, such as acceptance of pull requests, releases, designating developers as core contributors, etc.
- a governing body to make decisions and help guide the project.
This accomplishes a number of things, which as a project I think we need, such as:
- overall stability of the project.
- providing a system for conflict resolution.
- maintaining the spirit of yt as a team effort.
- providing a way for active contributors to get credit for their contribution in the form of official recognition.
So, these are my initial thoughts, but I really think this deserves a thorough discussion with as many people participating as possible. Please, think about what governance means to you, whether we need it, what it should be, and what we might get out of it, and share your thoughts over the next few days. I look forward to this discussion.
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I'm very in favor of putting some official procedures into a YTEP. Having
a codified process may also help with conflict resolution as well.
Apache does something with their projects where developers who make
sustained contribution are made "members" after nomination by another
member and are given write access to the main repo. It's a small thing,
but if we perhaps have an official definition of "yt member" in a YTEP with
a posted list of members, it can be something people can point to as a way
of demonstrating that they've done significant work on the project.
I think it might also be good to have officer-like positions where people
are representatives for various areas of the code, such as data structures,
visualization, analysis_modules, etc. and to have semi-regular meeting of
these people. This may be as much leadership as we need for now, just a
group that meets on a schedule to make sure everyone's on the same page
with releases and major development efforts.
What do people think of something like this?
On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk
Hi Britton,
Thanks for bringing this up -- it's a tough topic, but also I think really important. At the WSSSPE conference last year, a paper was submitted talking about the Apache model:
http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug...
which talks about a lot of related topics. Apache does some interesting things. They use the word "meritocracy" which I am rather -1 on using (see, for instance,
http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... ) but I do think there is something to be said for a large part of their methods of organization.
Like you, I think we are overdue. I would like to point out that, for all intents and purposes, you are *already* the ombudsman for the yt community. I don't think you're proposing we have a committee that bosses everyone around, but rather one that enables a larger number of people to have a say, particularly because yt has become embedded in many of our scientific workflows and it touches a lot of research activities now. I like the idea of members. I like the idea of a project management committee, but it's not clear to me how that would work, or which decisions we have made recently that they would weigh in on. I also really like the idea of having "code liasons" to different data platforms and/or communities, and the idea of having people who are responsible for many different areas of the code and codifying that in some way is quite attractive to me.
For what it's worth, a few weeks ago I gave a presentation on my "vision" for the future of yt (http://goo.gl/JKt6MA). The thing is, while I gave this presentation, it's just *my* vision -- it is not necessarily anyone else's vision. And I think it's time we have some method of taking into account a diverse set of opinions for what we as a community can emphasize, how we resolve conflicts, and so on and so forth.
Again, thanks for bringing this up. We need to have this conversation.
-Matt
On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith
wrote: Greeting yt developers,
First, I want to congratulate everyone here on the successful release of yt-3.0. This was a massive effort on the part of so many and a true testament to the strength of this team.
At the time of writing this, there are 78 members of the yt-dev mailing list. As someone who does most of their work in very small collaborations, this amazes me and make me very proud. In case you're wondering, the yt-users list has 268 members.
As a project, yt has a significant amount of infrastructure: code review with pull requests, issue tracking, automated testing, emails lists, an IRC channel, enhancement proposals, workshops. All of this is evidence of our legitimacy as a Real Thing. However, one big missing piece is a system of governance. I don't know exactly what this means, but I have some ideas, which I will share below. What I want to do right now is to start a discussion that will, hopefully, include as many people as possible on this list.
For me, governance means (roughly) the following:
- a set of procedures in writing for how various things are to be done, such as acceptance of pull requests, releases, designating developers as core contributors, etc.
- a governing body to make decisions and help guide the project.
This accomplishes a number of things, which as a project I think we need, such as:
- overall stability of the project.
- providing a system for conflict resolution.
- maintaining the spirit of yt as a team effort.
- providing a way for active contributors to get credit for their contribution in the form of official recognition.
So, these are my initial thoughts, but I really think this deserves a thorough discussion with as many people participating as possible. Please, think about what governance means to you, whether we need it, what it should be, and what we might get out of it, and share your thoughts over the next few days. I look forward to this discussion.
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hey Britton,
On Fri, Aug 15, 2014 at 2:50 PM, Britton Smith
I'm very in favor of putting some official procedures into a YTEP. Having a codified process may also help with conflict resolution as well.
Agreed. This should definitely be a YTEP.
Apache does something with their projects where developers who make sustained contribution are made "members" after nomination by another member and are given write access to the main repo. It's a small thing, but if we perhaps have an official definition of "yt member" in a YTEP with a posted list of members, it can be something people can point to as a way of demonstrating that they've done significant work on the project.
I really like this. I've seen other projects use "badges" as a way to indicate this as well. But I really like the idea of members. We should do this.
I think it might also be good to have officer-like positions where people are representatives for various areas of the code, such as data structures, visualization, analysis_modules, etc. and to have semi-regular meeting of these people. This may be as much leadership as we need for now, just a group that meets on a schedule to make sure everyone's on the same page with releases and major development efforts.
Yes! We absolutely need this. So for sure, I would think we need some type of "membership" and some type of "officer" structure. Does that sound right to others?
What do people think of something like this?
On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk
wrote: Hi Britton,
Thanks for bringing this up -- it's a tough topic, but also I think really important. At the WSSSPE conference last year, a paper was submitted talking about the Apache model:
http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug...
which talks about a lot of related topics. Apache does some interesting things. They use the word "meritocracy" which I am rather -1 on using (see, for instance,
http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... ) but I do think there is something to be said for a large part of their methods of organization.
Like you, I think we are overdue. I would like to point out that, for all intents and purposes, you are *already* the ombudsman for the yt community. I don't think you're proposing we have a committee that bosses everyone around, but rather one that enables a larger number of people to have a say, particularly because yt has become embedded in many of our scientific workflows and it touches a lot of research activities now. I like the idea of members. I like the idea of a project management committee, but it's not clear to me how that would work, or which decisions we have made recently that they would weigh in on. I also really like the idea of having "code liasons" to different data platforms and/or communities, and the idea of having people who are responsible for many different areas of the code and codifying that in some way is quite attractive to me.
For what it's worth, a few weeks ago I gave a presentation on my "vision" for the future of yt (http://goo.gl/JKt6MA). The thing is, while I gave this presentation, it's just *my* vision -- it is not necessarily anyone else's vision. And I think it's time we have some method of taking into account a diverse set of opinions for what we as a community can emphasize, how we resolve conflicts, and so on and so forth.
Again, thanks for bringing this up. We need to have this conversation.
-Matt
On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith
wrote: Greeting yt developers,
First, I want to congratulate everyone here on the successful release of yt-3.0. This was a massive effort on the part of so many and a true testament to the strength of this team.
At the time of writing this, there are 78 members of the yt-dev mailing list. As someone who does most of their work in very small collaborations, this amazes me and make me very proud. In case you're wondering, the yt-users list has 268 members.
As a project, yt has a significant amount of infrastructure: code review with pull requests, issue tracking, automated testing, emails lists, an IRC channel, enhancement proposals, workshops. All of this is evidence of our legitimacy as a Real Thing. However, one big missing piece is a system of governance. I don't know exactly what this means, but I have some ideas, which I will share below. What I want to do right now is to start a discussion that will, hopefully, include as many people as possible on this list.
For me, governance means (roughly) the following:
- a set of procedures in writing for how various things are to be done, such as acceptance of pull requests, releases, designating developers as core contributors, etc.
- a governing body to make decisions and help guide the project.
This accomplishes a number of things, which as a project I think we need, such as:
- overall stability of the project.
- providing a system for conflict resolution.
- maintaining the spirit of yt as a team effort.
- providing a way for active contributors to get credit for their contribution in the form of official recognition.
So, these are my initial thoughts, but I really think this deserves a thorough discussion with as many people participating as possible. Please, think about what governance means to you, whether we need it, what it should be, and what we might get out of it, and share your thoughts over the next few days. I look forward to this discussion.
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi,
I like the idea of members, and it’ll be a good idea to make it visible on the website. Then those people can get the recognition they deserve for their sustained efforts. This is very important when it comes time to apply for jobs, fellowships, computer time, and/or proposals, where you need to demonstrate something that’s not quantified by funds, papers, or citations.
Cheers,
John
On 15 Aug 2014, at 22:08, Matthew Turk
Hey Britton,
On Fri, Aug 15, 2014 at 2:50 PM, Britton Smith
wrote: I'm very in favor of putting some official procedures into a YTEP. Having a codified process may also help with conflict resolution as well.
Agreed. This should definitely be a YTEP.
Apache does something with their projects where developers who make sustained contribution are made "members" after nomination by another member and are given write access to the main repo. It's a small thing, but if we perhaps have an official definition of "yt member" in a YTEP with a posted list of members, it can be something people can point to as a way of demonstrating that they've done significant work on the project.
I really like this. I've seen other projects use "badges" as a way to indicate this as well. But I really like the idea of members. We should do this.
I think it might also be good to have officer-like positions where people are representatives for various areas of the code, such as data structures, visualization, analysis_modules, etc. and to have semi-regular meeting of these people. This may be as much leadership as we need for now, just a group that meets on a schedule to make sure everyone's on the same page with releases and major development efforts.
Yes! We absolutely need this.
So for sure, I would think we need some type of "membership" and some type of "officer" structure. Does that sound right to others?
What do people think of something like this?
On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk
wrote: Hi Britton,
Thanks for bringing this up -- it's a tough topic, but also I think really important. At the WSSSPE conference last year, a paper was submitted talking about the Apache model:
http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug...
which talks about a lot of related topics. Apache does some interesting things. They use the word "meritocracy" which I am rather -1 on using (see, for instance,
http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... ) but I do think there is something to be said for a large part of their methods of organization.
Like you, I think we are overdue. I would like to point out that, for all intents and purposes, you are *already* the ombudsman for the yt community. I don't think you're proposing we have a committee that bosses everyone around, but rather one that enables a larger number of people to have a say, particularly because yt has become embedded in many of our scientific workflows and it touches a lot of research activities now. I like the idea of members. I like the idea of a project management committee, but it's not clear to me how that would work, or which decisions we have made recently that they would weigh in on. I also really like the idea of having "code liasons" to different data platforms and/or communities, and the idea of having people who are responsible for many different areas of the code and codifying that in some way is quite attractive to me.
For what it's worth, a few weeks ago I gave a presentation on my "vision" for the future of yt (http://goo.gl/JKt6MA). The thing is, while I gave this presentation, it's just *my* vision -- it is not necessarily anyone else's vision. And I think it's time we have some method of taking into account a diverse set of opinions for what we as a community can emphasize, how we resolve conflicts, and so on and so forth.
Again, thanks for bringing this up. We need to have this conversation.
-Matt
On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith
wrote: Greeting yt developers,
First, I want to congratulate everyone here on the successful release of yt-3.0. This was a massive effort on the part of so many and a true testament to the strength of this team.
At the time of writing this, there are 78 members of the yt-dev mailing list. As someone who does most of their work in very small collaborations, this amazes me and make me very proud. In case you're wondering, the yt-users list has 268 members.
As a project, yt has a significant amount of infrastructure: code review with pull requests, issue tracking, automated testing, emails lists, an IRC channel, enhancement proposals, workshops. All of this is evidence of our legitimacy as a Real Thing. However, one big missing piece is a system of governance. I don't know exactly what this means, but I have some ideas, which I will share below. What I want to do right now is to start a discussion that will, hopefully, include as many people as possible on this list.
For me, governance means (roughly) the following:
- a set of procedures in writing for how various things are to be done, such as acceptance of pull requests, releases, designating developers as core contributors, etc.
- a governing body to make decisions and help guide the project.
This accomplishes a number of things, which as a project I think we need, such as:
- overall stability of the project.
- providing a system for conflict resolution.
- maintaining the spirit of yt as a team effort.
- providing a way for active contributors to get credit for their contribution in the form of official recognition.
So, these are my initial thoughts, but I really think this deserves a thorough discussion with as many people participating as possible. Please, think about what governance means to you, whether we need it, what it should be, and what we might get out of it, and share your thoughts over the next few days. I look forward to this discussion.
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech http://cosmo.gatech.edu
+1 to all suggestions
On Friday, August 15, 2014, Britton Smith
I'm very in favor of putting some official procedures into a YTEP. Having a codified process may also help with conflict resolution as well.
Apache does something with their projects where developers who make sustained contribution are made "members" after nomination by another member and are given write access to the main repo. It's a small thing, but if we perhaps have an official definition of "yt member" in a YTEP with a posted list of members, it can be something people can point to as a way of demonstrating that they've done significant work on the project.
I think it might also be good to have officer-like positions where people are representatives for various areas of the code, such as data structures, visualization, analysis_modules, etc. and to have semi-regular meeting of these people. This may be as much leadership as we need for now, just a group that meets on a schedule to make sure everyone's on the same page with releases and major development efforts.
What do people think of something like this?
On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk
javascript:_e(%7B%7D,'cvml','matthewturk@gmail.com');> wrote: Hi Britton,
Thanks for bringing this up -- it's a tough topic, but also I think really important. At the WSSSPE conference last year, a paper was submitted talking about the Apache model:
http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug...
which talks about a lot of related topics. Apache does some interesting things. They use the word "meritocracy" which I am rather -1 on using (see, for instance,
http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... ) but I do think there is something to be said for a large part of their methods of organization.
Like you, I think we are overdue. I would like to point out that, for all intents and purposes, you are *already* the ombudsman for the yt community. I don't think you're proposing we have a committee that bosses everyone around, but rather one that enables a larger number of people to have a say, particularly because yt has become embedded in many of our scientific workflows and it touches a lot of research activities now. I like the idea of members. I like the idea of a project management committee, but it's not clear to me how that would work, or which decisions we have made recently that they would weigh in on. I also really like the idea of having "code liasons" to different data platforms and/or communities, and the idea of having people who are responsible for many different areas of the code and codifying that in some way is quite attractive to me.
For what it's worth, a few weeks ago I gave a presentation on my "vision" for the future of yt (http://goo.gl/JKt6MA). The thing is, while I gave this presentation, it's just *my* vision -- it is not necessarily anyone else's vision. And I think it's time we have some method of taking into account a diverse set of opinions for what we as a community can emphasize, how we resolve conflicts, and so on and so forth.
Again, thanks for bringing this up. We need to have this conversation.
-Matt
On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith
javascript:_e(%7B%7D,'cvml','brittonsmith@gmail.com');> wrote: Greeting yt developers,
First, I want to congratulate everyone here on the successful release of yt-3.0. This was a massive effort on the part of so many and a true testament to the strength of this team.
At the time of writing this, there are 78 members of the yt-dev mailing list. As someone who does most of their work in very small collaborations, this amazes me and make me very proud. In case you're wondering, the yt-users list has 268 members.
As a project, yt has a significant amount of infrastructure: code review with pull requests, issue tracking, automated testing, emails lists, an IRC channel, enhancement proposals, workshops. All of this is evidence of our legitimacy as a Real Thing. However, one big missing piece is a system of governance. I don't know exactly what this means, but I have some ideas, which I will share below. What I want to do right now is to start a discussion that will, hopefully, include as many people as possible on this list.
For me, governance means (roughly) the following:
- a set of procedures in writing for how various things are to be done, such as acceptance of pull requests, releases, designating developers as core contributors, etc.
- a governing body to make decisions and help guide the project.
This accomplishes a number of things, which as a project I think we need, such as:
- overall stability of the project.
- providing a system for conflict resolution.
- maintaining the spirit of yt as a team effort.
- providing a way for active contributors to get credit for their contribution in the form of official recognition.
So, these are my initial thoughts, but I really think this deserves a thorough discussion with as many people participating as possible. Please, think about what governance means to you, whether we need it, what it should be, and what we might get out of it, and share your thoughts over the next few days. I look forward to this discussion.
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org javascript:_e(%7B%7D,'cvml','yt-dev@lists.spacepope.org'); http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org javascript:_e(%7B%7D,'cvml','yt-dev@lists.spacepope.org'); http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
these all sound like good ideas to me. Some simply operating procedures,
like "don't merge your own pull requests" might be good too.
On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith
I'm very in favor of putting some official procedures into a YTEP. Having a codified process may also help with conflict resolution as well.
Apache does something with their projects where developers who make sustained contribution are made "members" after nomination by another member and are given write access to the main repo. It's a small thing, but if we perhaps have an official definition of "yt member" in a YTEP with a posted list of members, it can be something people can point to as a way of demonstrating that they've done significant work on the project.
I think it might also be good to have officer-like positions where people are representatives for various areas of the code, such as data structures, visualization, analysis_modules, etc. and to have semi-regular meeting of these people. This may be as much leadership as we need for now, just a group that meets on a schedule to make sure everyone's on the same page with releases and major development efforts.
What do people think of something like this?
On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk
wrote: Hi Britton,
Thanks for bringing this up -- it's a tough topic, but also I think really important. At the WSSSPE conference last year, a paper was submitted talking about the Apache model:
http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug...
which talks about a lot of related topics. Apache does some interesting things. They use the word "meritocracy" which I am rather -1 on using (see, for instance,
http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... ) but I do think there is something to be said for a large part of their methods of organization.
Like you, I think we are overdue. I would like to point out that, for all intents and purposes, you are *already* the ombudsman for the yt community. I don't think you're proposing we have a committee that bosses everyone around, but rather one that enables a larger number of people to have a say, particularly because yt has become embedded in many of our scientific workflows and it touches a lot of research activities now. I like the idea of members. I like the idea of a project management committee, but it's not clear to me how that would work, or which decisions we have made recently that they would weigh in on. I also really like the idea of having "code liasons" to different data platforms and/or communities, and the idea of having people who are responsible for many different areas of the code and codifying that in some way is quite attractive to me.
For what it's worth, a few weeks ago I gave a presentation on my "vision" for the future of yt (http://goo.gl/JKt6MA). The thing is, while I gave this presentation, it's just *my* vision -- it is not necessarily anyone else's vision. And I think it's time we have some method of taking into account a diverse set of opinions for what we as a community can emphasize, how we resolve conflicts, and so on and so forth.
Again, thanks for bringing this up. We need to have this conversation.
-Matt
On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith
wrote: Greeting yt developers,
First, I want to congratulate everyone here on the successful release of yt-3.0. This was a massive effort on the part of so many and a true testament to the strength of this team.
At the time of writing this, there are 78 members of the yt-dev mailing list. As someone who does most of their work in very small collaborations, this amazes me and make me very proud. In case you're wondering, the yt-users list has 268 members.
As a project, yt has a significant amount of infrastructure: code review with pull requests, issue tracking, automated testing, emails lists, an IRC channel, enhancement proposals, workshops. All of this is evidence of our legitimacy as a Real Thing. However, one big missing piece is a system of governance. I don't know exactly what this means, but I have some ideas, which I will share below. What I want to do right now is to start a discussion that will, hopefully, include as many people as possible on this list.
For me, governance means (roughly) the following:
- a set of procedures in writing for how various things are to be done, such as acceptance of pull requests, releases, designating developers as core contributors, etc.
- a governing body to make decisions and help guide the project.
This accomplishes a number of things, which as a project I think we need, such as:
- overall stability of the project.
- providing a system for conflict resolution.
- maintaining the spirit of yt as a team effort.
- providing a way for active contributors to get credit for their contribution in the form of official recognition.
So, these are my initial thoughts, but I really think this deserves a thorough discussion with as many people participating as possible. Please, think about what governance means to you, whether we need it, what it should be, and what we might get out of it, and share your thoughts over the next few days. I look forward to this discussion.
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
I wanted to put my strong +1 out there even though I don't respond
often to dev emails. This sounds like a great direction for yt!
-Kenza
---
Kenza Arraki
PhD candidate
New Mexico State University
Department of Astronomy
On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale
these all sound like good ideas to me. Some simply operating procedures, like "don't merge your own pull requests" might be good too.
On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith
wrote: I'm very in favor of putting some official procedures into a YTEP. Having a codified process may also help with conflict resolution as well.
Apache does something with their projects where developers who make sustained contribution are made "members" after nomination by another member and are given write access to the main repo. It's a small thing, but if we perhaps have an official definition of "yt member" in a YTEP with a posted list of members, it can be something people can point to as a way of demonstrating that they've done significant work on the project.
I think it might also be good to have officer-like positions where people are representatives for various areas of the code, such as data structures, visualization, analysis_modules, etc. and to have semi-regular meeting of these people. This may be as much leadership as we need for now, just a group that meets on a schedule to make sure everyone's on the same page with releases and major development efforts.
What do people think of something like this?
On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk
wrote: Hi Britton,
Thanks for bringing this up -- it's a tough topic, but also I think really important. At the WSSSPE conference last year, a paper was submitted talking about the Apache model:
http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug...
which talks about a lot of related topics. Apache does some interesting things. They use the word "meritocracy" which I am rather -1 on using (see, for instance,
http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... ) but I do think there is something to be said for a large part of their methods of organization.
Like you, I think we are overdue. I would like to point out that, for all intents and purposes, you are *already* the ombudsman for the yt community. I don't think you're proposing we have a committee that bosses everyone around, but rather one that enables a larger number of people to have a say, particularly because yt has become embedded in many of our scientific workflows and it touches a lot of research activities now. I like the idea of members. I like the idea of a project management committee, but it's not clear to me how that would work, or which decisions we have made recently that they would weigh in on. I also really like the idea of having "code liasons" to different data platforms and/or communities, and the idea of having people who are responsible for many different areas of the code and codifying that in some way is quite attractive to me.
For what it's worth, a few weeks ago I gave a presentation on my "vision" for the future of yt (http://goo.gl/JKt6MA). The thing is, while I gave this presentation, it's just *my* vision -- it is not necessarily anyone else's vision. And I think it's time we have some method of taking into account a diverse set of opinions for what we as a community can emphasize, how we resolve conflicts, and so on and so forth.
Again, thanks for bringing this up. We need to have this conversation.
-Matt
On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith
wrote: Greeting yt developers,
First, I want to congratulate everyone here on the successful release of yt-3.0. This was a massive effort on the part of so many and a true testament to the strength of this team.
At the time of writing this, there are 78 members of the yt-dev mailing list. As someone who does most of their work in very small collaborations, this amazes me and make me very proud. In case you're wondering, the yt-users list has 268 members.
As a project, yt has a significant amount of infrastructure: code review with pull requests, issue tracking, automated testing, emails lists, an IRC channel, enhancement proposals, workshops. All of this is evidence of our legitimacy as a Real Thing. However, one big missing piece is a system of governance. I don't know exactly what this means, but I have some ideas, which I will share below. What I want to do right now is to start a discussion that will, hopefully, include as many people as possible on this list.
For me, governance means (roughly) the following:
- a set of procedures in writing for how various things are to be done, such as acceptance of pull requests, releases, designating developers as core contributors, etc.
- a governing body to make decisions and help guide the project.
This accomplishes a number of things, which as a project I think we need, such as:
- overall stability of the project.
- providing a system for conflict resolution.
- maintaining the spirit of yt as a team effort.
- providing a way for active contributors to get credit for their contribution in the form of official recognition.
So, these are my initial thoughts, but I really think this deserves a thorough discussion with as many people participating as possible. Please, think about what governance means to you, whether we need it, what it should be, and what we might get out of it, and share your thoughts over the next few days. I look forward to this discussion.
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1 as well on all suggestions
On Aug 15, 2014, at 5:32 PM, Kenza Arraki
wrote: I wanted to put my strong +1 out there even though I don't respond often to dev emails. This sounds like a great direction for yt!
-Kenza
--- Kenza Arraki PhD candidate New Mexico State University Department of Astronomy
On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale
wrote: these all sound like good ideas to me. Some simply operating procedures, like "don't merge your own pull requests" might be good too.
On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith
wrote: I'm very in favor of putting some official procedures into a YTEP. Having a codified process may also help with conflict resolution as well.
Apache does something with their projects where developers who make sustained contribution are made "members" after nomination by another member and are given write access to the main repo. It's a small thing, but if we perhaps have an official definition of "yt member" in a YTEP with a posted list of members, it can be something people can point to as a way of demonstrating that they've done significant work on the project.
I think it might also be good to have officer-like positions where people are representatives for various areas of the code, such as data structures, visualization, analysis_modules, etc. and to have semi-regular meeting of these people. This may be as much leadership as we need for now, just a group that meets on a schedule to make sure everyone's on the same page with releases and major development efforts.
What do people think of something like this?
On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk
wrote: Hi Britton,
Thanks for bringing this up -- it's a tough topic, but also I think really important. At the WSSSPE conference last year, a paper was submitted talking about the Apache model:
http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug...
which talks about a lot of related topics. Apache does some interesting things. They use the word "meritocracy" which I am rather -1 on using (see, for instance,
http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... ) but I do think there is something to be said for a large part of their methods of organization.
Like you, I think we are overdue. I would like to point out that, for all intents and purposes, you are *already* the ombudsman for the yt community. I don't think you're proposing we have a committee that bosses everyone around, but rather one that enables a larger number of people to have a say, particularly because yt has become embedded in many of our scientific workflows and it touches a lot of research activities now. I like the idea of members. I like the idea of a project management committee, but it's not clear to me how that would work, or which decisions we have made recently that they would weigh in on. I also really like the idea of having "code liasons" to different data platforms and/or communities, and the idea of having people who are responsible for many different areas of the code and codifying that in some way is quite attractive to me.
For what it's worth, a few weeks ago I gave a presentation on my "vision" for the future of yt (http://goo.gl/JKt6MA). The thing is, while I gave this presentation, it's just *my* vision -- it is not necessarily anyone else's vision. And I think it's time we have some method of taking into account a diverse set of opinions for what we as a community can emphasize, how we resolve conflicts, and so on and so forth.
Again, thanks for bringing this up. We need to have this conversation.
-Matt
On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith
wrote: Greeting yt developers,
First, I want to congratulate everyone here on the successful release of yt-3.0. This was a massive effort on the part of so many and a true testament to the strength of this team.
At the time of writing this, there are 78 members of the yt-dev mailing list. As someone who does most of their work in very small collaborations, this amazes me and make me very proud. In case you're wondering, the yt-users list has 268 members.
As a project, yt has a significant amount of infrastructure: code review with pull requests, issue tracking, automated testing, emails lists, an IRC channel, enhancement proposals, workshops. All of this is evidence of our legitimacy as a Real Thing. However, one big missing piece is a system of governance. I don't know exactly what this means, but I have some ideas, which I will share below. What I want to do right now is to start a discussion that will, hopefully, include as many people as possible on this list.
For me, governance means (roughly) the following:
- a set of procedures in writing for how various things are to be done, such as acceptance of pull requests, releases, designating developers as core contributors, etc.
- a governing body to make decisions and help guide the project.
This accomplishes a number of things, which as a project I think we need, such as:
- overall stability of the project.
- providing a system for conflict resolution.
- maintaining the spirit of yt as a team effort.
- providing a way for active contributors to get credit for their contribution in the form of official recognition.
So, these are my initial thoughts, but I really think this deserves a thorough discussion with as many people participating as possible. Please, think about what governance means to you, whether we need it, what it should be, and what we might get out of it, and share your thoughts over the next few days. I look forward to this discussion.
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1, absolutely. Right now, yt has a really high bus factor. I think this
would help that a lot.
On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone
+1 as well on all suggestions
On Aug 15, 2014, at 5:32 PM, Kenza Arraki
wrote: I wanted to put my strong +1 out there even though I don't respond often to dev emails. This sounds like a great direction for yt!
-Kenza
--- Kenza Arraki PhD candidate New Mexico State University Department of Astronomy
these all sound like good ideas to me. Some simply operating
like "don't merge your own pull requests" might be good too.
On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith
wrote: I'm very in favor of putting some official procedures into a YTEP.
Having
a codified process may also help with conflict resolution as well.
Apache does something with their projects where developers who make sustained contribution are made "members" after nomination by another member and are given write access to the main repo. It's a small thing, but if we perhaps have an official definition of "yt member" in a YTEP with a
list of members, it can be something people can point to as a way of demonstrating that they've done significant work on the project.
I think it might also be good to have officer-like positions where
are representatives for various areas of the code, such as data structures, visualization, analysis_modules, etc. and to have semi-regular meeting of these people. This may be as much leadership as we need for now, just a group that meets on a schedule to make sure everyone's on the same
On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale
wrote: procedures, posted people page with releases and major development efforts.
What do people think of something like this?
On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk
wrote: Hi Britton,
Thanks for bringing this up -- it's a tough topic, but also I think really important. At the WSSSPE conference last year, a paper was submitted talking about the Apache model:
http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug...
which talks about a lot of related topics. Apache does some interesting things. They use the word "meritocracy" which I am rather -1 on using (see, for instance,
http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun...
) but I do think there is something to be said for a large part of their methods of organization.
Like you, I think we are overdue. I would like to point out that, for all intents and purposes, you are *already* the ombudsman for the yt community. I don't think you're proposing we have a committee that bosses everyone around, but rather one that enables a larger number of people to have a say, particularly because yt has become embedded in many of our scientific workflows and it touches a lot of research activities now. I like the idea of members. I like the idea of a project management committee, but it's not clear to me how that would work, or which decisions we have made recently that they would weigh in on. I also really like the idea of having "code liasons" to different data platforms and/or communities, and the idea of having people who are responsible for many different areas of the code and codifying that in some way is quite attractive to me.
For what it's worth, a few weeks ago I gave a presentation on my "vision" for the future of yt (http://goo.gl/JKt6MA). The thing is, while I gave this presentation, it's just *my* vision -- it is not necessarily anyone else's vision. And I think it's time we have some method of taking into account a diverse set of opinions for what we as a community can emphasize, how we resolve conflicts, and so on and so forth.
Again, thanks for bringing this up. We need to have this conversation.
-Matt
On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith < brittonsmith@gmail.com> wrote:
Greeting yt developers,
First, I want to congratulate everyone here on the successful release of yt-3.0. This was a massive effort on the part of so many and a true testament to the strength of this team.
At the time of writing this, there are 78 members of the yt-dev mailing list. As someone who does most of their work in very small collaborations, this amazes me and make me very proud. In case you're wondering, the yt-users list has 268 members.
As a project, yt has a significant amount of infrastructure: code review with pull requests, issue tracking, automated testing, emails lists, an IRC channel, enhancement proposals, workshops. All of this is evidence of our legitimacy as a Real Thing. However, one big missing piece is a system of governance. I don't know exactly what this means, but I have some ideas, which I will share below. What I want to do right now is to start a discussion that will, hopefully, include as many people as possible on this list.
For me, governance means (roughly) the following:
- a set of procedures in writing for how various things are to be done, such as acceptance of pull requests, releases, designating developers as core contributors, etc.
- a governing body to make decisions and help guide the project.
This accomplishes a number of things, which as a project I think we need, such as:
- overall stability of the project.
- providing a system for conflict resolution.
- maintaining the spirit of yt as a team effort.
- providing a way for active contributors to get credit for their contribution in the form of official recognition.
So, these are my initial thoughts, but I really think this deserves a thorough discussion with as many people participating as possible. Please, think about what governance means to you, whether we need it, what it should be, and what we might get out of it, and share your thoughts over the next few days. I look forward to this discussion.
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all,
Britton -- I really like these ideas, and I like the member level being
defined as write access.
I'm a bit more concerned about the officers designation in terms of the
logistics of matching people with sections of the code. I could see
something working where on a 6-month basis, each of the main areas in yt
are assigned a lead. That lead isn't necessarily the person who has
written the most in the area, but rather a person who is willing to keep
track of that area of the codebase for the next 6 months, so that when it
comes to doing releases, they are the ones that know what has changed and
where things are not working well. Maybe that's too much of a process, but
I also think we should be wary of assigning potentially long-lasting labels
to either people or code. Semi-regular meetings for this set of people
would be great.
Anyways, I'm definitely a +1 on a YTEP for all of this, and look forward to
hearing more!
Cheers,
Sam
On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller
+1, absolutely. Right now, yt has a really high bus factor. I think this would help that a lot.
On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone
wrote: +1 as well on all suggestions
On Aug 15, 2014, at 5:32 PM, Kenza Arraki
wrote: I wanted to put my strong +1 out there even though I don't respond often to dev emails. This sounds like a great direction for yt!
-Kenza
--- Kenza Arraki PhD candidate New Mexico State University Department of Astronomy
these all sound like good ideas to me. Some simply operating
On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale
wrote: procedures, like "don't merge your own pull requests" might be good too.
On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith
wrote:
I'm very in favor of putting some official procedures into a YTEP.
a codified process may also help with conflict resolution as well.
Apache does something with their projects where developers who make sustained contribution are made "members" after nomination by another member and are given write access to the main repo. It's a small thing, but if we perhaps have an official definition of "yt member" in a YTEP with a
list of members, it can be something people can point to as a way of demonstrating that they've done significant work on the project.
I think it might also be good to have officer-like positions where
are representatives for various areas of the code, such as data structures, visualization, analysis_modules, etc. and to have semi-regular meeting of these people. This may be as much leadership as we need for now, just a group that meets on a schedule to make sure everyone's on the same
releases and major development efforts.
What do people think of something like this?
On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk
wrote: Hi Britton,
Thanks for bringing this up -- it's a tough topic, but also I think really important. At the WSSSPE conference last year, a paper was submitted talking about the Apache model:
http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug...
which talks about a lot of related topics. Apache does some interesting things. They use the word "meritocracy" which I am
rather
-1 on using (see, for instance,
http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun...
) but I do think there is something to be said for a large part of their methods of organization.
Like you, I think we are overdue. I would like to point out that, for all intents and purposes, you are *already* the ombudsman for the yt community. I don't think you're proposing we have a committee that bosses everyone around, but rather one that enables a larger number of people to have a say, particularly because yt has become embedded in many of our scientific workflows and it touches a lot of research activities now. I like the idea of members. I like the idea of a project management committee, but it's not clear to me how that would work, or which decisions we have made recently that they would weigh in on. I also really like the idea of having "code liasons" to different data platforms and/or communities, and the idea of having people who are responsible for many different areas of the code and codifying that in some way is quite attractive to me.
For what it's worth, a few weeks ago I gave a presentation on my "vision" for the future of yt (http://goo.gl/JKt6MA). The thing is, while I gave this presentation, it's just *my* vision -- it is not necessarily anyone else's vision. And I think it's time we have some method of taking into account a diverse set of opinions for what we as a community can emphasize, how we resolve conflicts, and so on and so forth.
Again, thanks for bringing this up. We need to have this conversation.
-Matt
On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith < brittonsmith@gmail.com> wrote: > Greeting yt developers, > > First, I want to congratulate everyone here on the successful release > of yt-3.0. This was a massive effort on the part of so many and a > true testament to the strength of this team. > > At the time of writing this, there are 78 members of the yt-dev > mailing list. As someone who does most of their work in very small > collaborations, this amazes me and make me very proud. In case you're > wondering, the yt-users list has 268 members. > > As a project, yt has a significant amount of infrastructure: code > review with pull requests, issue tracking, automated testing, emails > lists, an IRC channel, enhancement proposals, workshops. All of
Having posted people page with this
> is evidence of our legitimacy as a Real Thing. However, one big > missing piece is a system of governance. I don't know exactly what > this means, but I have some ideas, which I will share below. What I > want to do right now is to start a discussion that will, hopefully, > include as many people as possible on this list. > > For me, governance means (roughly) the following: > > - a set of procedures in writing for how various things are to be > done, such as acceptance of pull requests, releases, designating > developers as core contributors, etc. > > - a governing body to make decisions and help guide the project. > > This accomplishes a number of things, which as a project I think we > need, such as: > > - overall stability of the project. > > - providing a system for conflict resolution. > > - maintaining the spirit of yt as a team effort. > > - providing a way for active contributors to get credit for their > contribution in the form of official recognition. > > > So, these are my initial thoughts, but I really think this deserves a > thorough discussion with as many people participating as possible. > Please, think about what governance means to you, whether we need it, > what it should be, and what we might get out of it, and share your > thoughts over the next few days. I look forward to this discussion. > > Britton > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Sam,
This is an excellent point. I think it's important not to overburden a
single person by being forever responsible for a large chunk of the code.
I also think it's good to give as many as are willing an opportunity to
share the role. Perhaps there is a team of people or subcommittee that is
responsible for figuring out who their representative is. This can be
ironed out.
I think we've gotten enough positive response to start thinking about a
YTEP that lays it all out. I will start something this week, ask for
feedback, and we can all develop this together.
In the mean time, if you would still like to chime in on this discussion,
please do so.
Thanks, everyone.
Britton
On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman
Hi all,
Britton -- I really like these ideas, and I like the member level being defined as write access.
I'm a bit more concerned about the officers designation in terms of the logistics of matching people with sections of the code. I could see something working where on a 6-month basis, each of the main areas in yt are assigned a lead. That lead isn't necessarily the person who has written the most in the area, but rather a person who is willing to keep track of that area of the codebase for the next 6 months, so that when it comes to doing releases, they are the ones that know what has changed and where things are not working well. Maybe that's too much of a process, but I also think we should be wary of assigning potentially long-lasting labels to either people or code. Semi-regular meetings for this set of people would be great.
Anyways, I'm definitely a +1 on a YTEP for all of this, and look forward to hearing more!
Cheers, Sam
On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller
wrote: +1, absolutely. Right now, yt has a really high bus factor. I think this would help that a lot.
On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone
wrote: +1 as well on all suggestions
On Aug 15, 2014, at 5:32 PM, Kenza Arraki
wrote: I wanted to put my strong +1 out there even though I don't respond often to dev emails. This sounds like a great direction for yt!
-Kenza
--- Kenza Arraki PhD candidate New Mexico State University Department of Astronomy
these all sound like good ideas to me. Some simply operating
like "don't merge your own pull requests" might be good too.
On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith < brittonsmith@gmail.com> wrote:
I'm very in favor of putting some official procedures into a YTEP.
Having
a codified process may also help with conflict resolution as well.
Apache does something with their projects where developers who make sustained contribution are made "members" after nomination by another member and are given write access to the main repo. It's a small thing, but if we perhaps have an official definition of "yt member" in a YTEP with a
list of members, it can be something people can point to as a way of demonstrating that they've done significant work on the project.
I think it might also be good to have officer-like positions where
are representatives for various areas of the code, such as data structures, visualization, analysis_modules, etc. and to have semi-regular meeting of these people. This may be as much leadership as we need for now, just a group that meets on a schedule to make sure everyone's on the same
On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale
wrote: procedures, posted people page with releases and major development efforts.
What do people think of something like this?
On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk
wrote: > > Hi Britton, > > Thanks for bringing this up -- it's a tough topic, but also I think > really important. At the WSSSPE conference last year, a paper was > submitted talking about the Apache model: > > > http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... > > which talks about a lot of related topics. Apache does some > interesting things. They use the word "meritocracy" which I am rather > -1 on using (see, for instance, > > http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... > ) but I do think there is something to be said for a large part of > their methods of organization. > > Like you, I think we are overdue. I would like to point out that, for > all intents and purposes, you are *already* the ombudsman for the yt > community. I don't think you're proposing we have a committee that > bosses everyone around, but rather one that enables a larger number of > people to have a say, particularly because yt has become embedded in > many of our scientific workflows and it touches a lot of research > activities now. I like the idea of members. I like the idea of a > project management committee, but it's not clear to me how that would > work, or which decisions we have made recently that they would weigh > in on. I also really like the idea of having "code liasons" to > different data platforms and/or communities, and the idea of having > people who are responsible for many different areas of the code and > codifying that in some way is quite attractive to me. > > For what it's worth, a few weeks ago I gave a presentation on my > "vision" for the future of yt (http://goo.gl/JKt6MA). The thing is, > while I gave this presentation, it's just *my* vision -- it is not > necessarily anyone else's vision. And I think it's time we have some > method of taking into account a diverse set of opinions for what we as > a community can emphasize, how we resolve conflicts, and so on and so > forth. > > Again, thanks for bringing this up. We need to have this conversation. > > -Matt > > On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith < brittonsmith@gmail.com> > wrote: >> Greeting yt developers, >> >> First, I want to congratulate everyone here on the successful release >> of yt-3.0. This was a massive effort on the part of so many and a >> true testament to the strength of this team. >> >> At the time of writing this, there are 78 members of the yt-dev >> mailing list. As someone who does most of their work in very small >> collaborations, this amazes me and make me very proud. In case you're >> wondering, the yt-users list has 268 members. >> >> As a project, yt has a significant amount of infrastructure: code >> review with pull requests, issue tracking, automated testing, emails >> lists, an IRC channel, enhancement proposals, workshops. All of this >> is evidence of our legitimacy as a Real Thing. However, one big >> missing piece is a system of governance. I don't know exactly what >> this means, but I have some ideas, which I will share below. What I >> want to do right now is to start a discussion that will, hopefully, >> include as many people as possible on this list. >> >> For me, governance means (roughly) the following: >> >> - a set of procedures in writing for how various things are to be >> done, such as acceptance of pull requests, releases, designating >> developers as core contributors, etc. >> >> - a governing body to make decisions and help guide the project. >> >> This accomplishes a number of things, which as a project I think we >> need, such as: >> >> - overall stability of the project. >> >> - providing a system for conflict resolution. >> >> - maintaining the spirit of yt as a team effort. >> >> - providing a way for active contributors to get credit for their >> contribution in the form of official recognition. >> >> >> So, these are my initial thoughts, but I really think this deserves a >> thorough discussion with as many people participating as possible. >> Please, think about what governance means to you, whether we need it, >> what it should be, and what we might get out of it, and share your >> thoughts over the next few days. I look forward to this discussion. >> >> Britton >> >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi everyone,
I have just issued a pull request to the YTEP repository containing an
initial draft of yt team guidelines. I encourage everyone to take a look
at it and offer their feedback. In case you don't get the notification,
the PR can be viewed here:
https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras...
Britton
On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith
Hi Sam,
This is an excellent point. I think it's important not to overburden a single person by being forever responsible for a large chunk of the code. I also think it's good to give as many as are willing an opportunity to share the role. Perhaps there is a team of people or subcommittee that is responsible for figuring out who their representative is. This can be ironed out.
I think we've gotten enough positive response to start thinking about a YTEP that lays it all out. I will start something this week, ask for feedback, and we can all develop this together.
In the mean time, if you would still like to chime in on this discussion, please do so. Thanks, everyone.
Britton
On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman
wrote: Hi all,
Britton -- I really like these ideas, and I like the member level being defined as write access.
I'm a bit more concerned about the officers designation in terms of the logistics of matching people with sections of the code. I could see something working where on a 6-month basis, each of the main areas in yt are assigned a lead. That lead isn't necessarily the person who has written the most in the area, but rather a person who is willing to keep track of that area of the codebase for the next 6 months, so that when it comes to doing releases, they are the ones that know what has changed and where things are not working well. Maybe that's too much of a process, but I also think we should be wary of assigning potentially long-lasting labels to either people or code. Semi-regular meetings for this set of people would be great.
Anyways, I'm definitely a +1 on a YTEP for all of this, and look forward to hearing more!
Cheers, Sam
On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller
wrote: +1, absolutely. Right now, yt has a really high bus factor. I think this would help that a lot.
On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone
wrote: +1 as well on all suggestions
On Aug 15, 2014, at 5:32 PM, Kenza Arraki
wrote: I wanted to put my strong +1 out there even though I don't respond often to dev emails. This sounds like a great direction for yt!
-Kenza
--- Kenza Arraki PhD candidate New Mexico State University Department of Astronomy
these all sound like good ideas to me. Some simply operating
like "don't merge your own pull requests" might be good too.
On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith < brittonsmith@gmail.com> wrote: > > I'm very in favor of putting some official procedures into a YTEP. Having > a codified process may also help with conflict resolution as well. > > Apache does something with their projects where developers who make > sustained contribution are made "members" after nomination by another member > and are given write access to the main repo. It's a small thing, but if we > perhaps have an official definition of "yt member" in a YTEP with a
> list of members, it can be something people can point to as a way of > demonstrating that they've done significant work on the project. > > I think it might also be good to have officer-like positions where
> are representatives for various areas of the code, such as data structures, > visualization, analysis_modules, etc. and to have semi-regular meeting of > these people. This may be as much leadership as we need for now, just a > group that meets on a schedule to make sure everyone's on the same
> releases and major development efforts. > > What do people think of something like this? > > On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk < matthewturk@gmail.com> > wrote: >> >> Hi Britton, >> >> Thanks for bringing this up -- it's a tough topic, but also I think >> really important. At the WSSSPE conference last year, a paper was >> submitted talking about the Apache model: >> >> >> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... >> >> which talks about a lot of related topics. Apache does some >> interesting things. They use the word "meritocracy" which I am rather >> -1 on using (see, for instance, >> >> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... >> ) but I do think there is something to be said for a large part of >> their methods of organization. >> >> Like you, I think we are overdue. I would like to point out that, for >> all intents and purposes, you are *already* the ombudsman for the yt >> community. I don't think you're proposing we have a committee that >> bosses everyone around, but rather one that enables a larger number of >> people to have a say, particularly because yt has become embedded in >> many of our scientific workflows and it touches a lot of research >> activities now. I like the idea of members. I like the idea of a >> project management committee, but it's not clear to me how that would >> work, or which decisions we have made recently that they would weigh >> in on. I also really like the idea of having "code liasons" to >> different data platforms and/or communities, and the idea of having >> people who are responsible for many different areas of the code and >> codifying that in some way is quite attractive to me. >> >> For what it's worth, a few weeks ago I gave a presentation on my >> "vision" for the future of yt (http://goo.gl/JKt6MA). The thing is, >> while I gave this presentation, it's just *my* vision -- it is not >> necessarily anyone else's vision. And I think it's time we have some >> method of taking into account a diverse set of opinions for what we as >> a community can emphasize, how we resolve conflicts, and so on and so >> forth. >> >> Again, thanks for bringing this up. We need to have this conversation. >> >> -Matt >> >> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith < brittonsmith@gmail.com> >> wrote: >>> Greeting yt developers, >>> >>> First, I want to congratulate everyone here on the successful release >>> of yt-3.0. This was a massive effort on the part of so many and a >>> true testament to the strength of this team. >>> >>> At the time of writing this, there are 78 members of the yt-dev >>> mailing list. As someone who does most of their work in very small >>> collaborations, this amazes me and make me very proud. In case you're >>> wondering, the yt-users list has 268 members. >>> >>> As a project, yt has a significant amount of infrastructure: code >>> review with pull requests, issue tracking, automated testing, emails >>> lists, an IRC channel, enhancement proposals, workshops. All of
On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale
wrote: procedures, posted people page with this >>> is evidence of our legitimacy as a Real Thing. However, one big >>> missing piece is a system of governance. I don't know exactly what >>> this means, but I have some ideas, which I will share below. What I >>> want to do right now is to start a discussion that will, hopefully, >>> include as many people as possible on this list. >>> >>> For me, governance means (roughly) the following: >>> >>> - a set of procedures in writing for how various things are to be >>> done, such as acceptance of pull requests, releases, designating >>> developers as core contributors, etc. >>> >>> - a governing body to make decisions and help guide the project. >>> >>> This accomplishes a number of things, which as a project I think we >>> need, such as: >>> >>> - overall stability of the project. >>> >>> - providing a system for conflict resolution. >>> >>> - maintaining the spirit of yt as a team effort. >>> >>> - providing a way for active contributors to get credit for their >>> contribution in the form of official recognition. >>> >>> >>> So, these are my initial thoughts, but I really think this deserves a >>> thorough discussion with as many people participating as possible. >>> Please, think about what governance means to you, whether we need it, >>> what it should be, and what we might get out of it, and share your >>> thoughts over the next few days. I look forward to this discussion. >>> >>> Britton >>> >>> >>> _______________________________________________ >>> yt-dev mailing list >>> yt-dev@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Britton,
I think this is really, really important, and I'm really happy with
the YTEP as it stands.
We've only gotten feedback from a few people. I think it's really
important to get both positive and negative feedback from people on
this -- even to the level of "geez, stop taking yourselves so
seriously!" :) Do you think maybe an email to the yt-users mailing
list would be productive? Or even directly writing to the people
identified as "founding" members?
-Matt
On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith
Hi everyone,
I have just issued a pull request to the YTEP repository containing an initial draft of yt team guidelines. I encourage everyone to take a look at it and offer their feedback. In case you don't get the notification, the PR can be viewed here: https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras...
Britton
On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith
wrote: Hi Sam,
This is an excellent point. I think it's important not to overburden a single person by being forever responsible for a large chunk of the code. I also think it's good to give as many as are willing an opportunity to share the role. Perhaps there is a team of people or subcommittee that is responsible for figuring out who their representative is. This can be ironed out.
I think we've gotten enough positive response to start thinking about a YTEP that lays it all out. I will start something this week, ask for feedback, and we can all develop this together.
In the mean time, if you would still like to chime in on this discussion, please do so. Thanks, everyone.
Britton
On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman
wrote: Hi all,
Britton -- I really like these ideas, and I like the member level being defined as write access.
I'm a bit more concerned about the officers designation in terms of the logistics of matching people with sections of the code. I could see something working where on a 6-month basis, each of the main areas in yt are assigned a lead. That lead isn't necessarily the person who has written the most in the area, but rather a person who is willing to keep track of that area of the codebase for the next 6 months, so that when it comes to doing releases, they are the ones that know what has changed and where things are not working well. Maybe that's too much of a process, but I also think we should be wary of assigning potentially long-lasting labels to either people or code. Semi-regular meetings for this set of people would be great.
Anyways, I'm definitely a +1 on a YTEP for all of this, and look forward to hearing more!
Cheers, Sam
On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller
wrote: +1, absolutely. Right now, yt has a really high bus factor. I think this would help that a lot.
On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone
wrote: +1 as well on all suggestions
On Aug 15, 2014, at 5:32 PM, Kenza Arraki
wrote: I wanted to put my strong +1 out there even though I don't respond often to dev emails. This sounds like a great direction for yt!
-Kenza
--- Kenza Arraki PhD candidate New Mexico State University Department of Astronomy
On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale
wrote: > these all sound like good ideas to me. Some simply operating > procedures, > like "don't merge your own pull requests" might be good too. > > > On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith > > wrote: >> >> I'm very in favor of putting some official procedures into a YTEP. >> Having >> a codified process may also help with conflict resolution as well. >> >> Apache does something with their projects where developers who make >> sustained contribution are made "members" after nomination by >> another member >> and are given write access to the main repo. It's a small thing, >> but if we >> perhaps have an official definition of "yt member" in a YTEP with a >> posted >> list of members, it can be something people can point to as a way >> of >> demonstrating that they've done significant work on the project. >> >> I think it might also be good to have officer-like positions where >> people >> are representatives for various areas of the code, such as data >> structures, >> visualization, analysis_modules, etc. and to have semi-regular >> meeting of >> these people. This may be as much leadership as we need for now, >> just a >> group that meets on a schedule to make sure everyone's on the same >> page with >> releases and major development efforts. >> >> What do people think of something like this? >> >> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk >> >> wrote: >>> >>> Hi Britton, >>> >>> Thanks for bringing this up -- it's a tough topic, but also I >>> think >>> really important. At the WSSSPE conference last year, a paper was >>> submitted talking about the Apache model: >>> >>> >>> >>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... >>> >>> which talks about a lot of related topics. Apache does some >>> interesting things. They use the word "meritocracy" which I am >>> rather >>> -1 on using (see, for instance, >>> >>> >>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... >>> ) but I do think there is something to be said for a large part of >>> their methods of organization. >>> >>> Like you, I think we are overdue. I would like to point out that, >>> for >>> all intents and purposes, you are *already* the ombudsman for the >>> yt >>> community. I don't think you're proposing we have a committee >>> that >>> bosses everyone around, but rather one that enables a larger >>> number of >>> people to have a say, particularly because yt has become embedded >>> in >>> many of our scientific workflows and it touches a lot of research >>> activities now. I like the idea of members. I like the idea of a >>> project management committee, but it's not clear to me how that >>> would >>> work, or which decisions we have made recently that they would >>> weigh >>> in on. I also really like the idea of having "code liasons" to >>> different data platforms and/or communities, and the idea of >>> having >>> people who are responsible for many different areas of the code >>> and >>> codifying that in some way is quite attractive to me. >>> >>> For what it's worth, a few weeks ago I gave a presentation on my >>> "vision" for the future of yt (http://goo.gl/JKt6MA). The thing >>> is, >>> while I gave this presentation, it's just *my* vision -- it is not >>> necessarily anyone else's vision. And I think it's time we have >>> some >>> method of taking into account a diverse set of opinions for what >>> we as >>> a community can emphasize, how we resolve conflicts, and so on and >>> so >>> forth. >>> >>> Again, thanks for bringing this up. We need to have this >>> conversation. >>> >>> -Matt >>> >>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith >>> >>> wrote: >>>> Greeting yt developers, >>>> >>>> First, I want to congratulate everyone here on the successful >>>> release >>>> of yt-3.0. This was a massive effort on the part of so many and >>>> a >>>> true testament to the strength of this team. >>>> >>>> At the time of writing this, there are 78 members of the yt-dev >>>> mailing list. As someone who does most of their work in very >>>> small >>>> collaborations, this amazes me and make me very proud. In case >>>> you're >>>> wondering, the yt-users list has 268 members. >>>> >>>> As a project, yt has a significant amount of infrastructure: code >>>> review with pull requests, issue tracking, automated testing, >>>> emails >>>> lists, an IRC channel, enhancement proposals, workshops. All of >>>> this >>>> is evidence of our legitimacy as a Real Thing. However, one big >>>> missing piece is a system of governance. I don't know exactly >>>> what >>>> this means, but I have some ideas, which I will share below. >>>> What I >>>> want to do right now is to start a discussion that will, >>>> hopefully, >>>> include as many people as possible on this list. >>>> >>>> For me, governance means (roughly) the following: >>>> >>>> - a set of procedures in writing for how various things are to be >>>> done, such as acceptance of pull requests, releases, designating >>>> developers as core contributors, etc. >>>> >>>> - a governing body to make decisions and help guide the project. >>>> >>>> This accomplishes a number of things, which as a project I think >>>> we >>>> need, such as: >>>> >>>> - overall stability of the project. >>>> >>>> - providing a system for conflict resolution. >>>> >>>> - maintaining the spirit of yt as a team effort. >>>> >>>> - providing a way for active contributors to get credit for their >>>> contribution in the form of official recognition. >>>> >>>> >>>> So, these are my initial thoughts, but I really think this >>>> deserves a >>>> thorough discussion with as many people participating as >>>> possible. >>>> Please, think about what governance means to you, whether we need >>>> it, >>>> what it should be, and what we might get out of it, and share >>>> your >>>> thoughts over the next few days. I look forward to this >>>> discussion. >>>> >>>> Britton >>>> >>>> >>>> _______________________________________________ >>>> yt-dev mailing list >>>> yt-dev@lists.spacepope.org >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> _______________________________________________ >>> yt-dev mailing list >>> yt-dev@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > -- > Michael Zingale > Associate Professor > > Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, > NY > 11794-3800 > phone: 631-632-8225 > e-mail: Michael.Zingale@stonybrook.edu > web: http://www.astro.sunysb.edu/mzingale > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi All,
Seems reasonable to me.
Be Well
Anthony
On Tue, Aug 26, 2014 at 3:20 PM, Matthew Turk
Hi Britton,
I think this is really, really important, and I'm really happy with the YTEP as it stands.
We've only gotten feedback from a few people. I think it's really important to get both positive and negative feedback from people on this -- even to the level of "geez, stop taking yourselves so seriously!" :) Do you think maybe an email to the yt-users mailing list would be productive? Or even directly writing to the people identified as "founding" members?
-Matt
Hi everyone,
I have just issued a pull request to the YTEP repository containing an initial draft of yt team guidelines. I encourage everyone to take a look at it and offer their feedback. In case you don't get the notification,
On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith
wrote: the PR can be viewed here:
https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras...
Britton
On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith
wrote: Hi Sam,
This is an excellent point. I think it's important not to overburden a single person by being forever responsible for a large chunk of the
also think it's good to give as many as are willing an opportunity to share the role. Perhaps there is a team of people or subcommittee that is responsible for figuring out who their representative is. This can be ironed out.
I think we've gotten enough positive response to start thinking about a YTEP that lays it all out. I will start something this week, ask for feedback, and we can all develop this together.
In the mean time, if you would still like to chime in on this discussion, please do so. Thanks, everyone.
Britton
On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman
wrote: Hi all,
Britton -- I really like these ideas, and I like the member level being defined as write access.
I'm a bit more concerned about the officers designation in terms of the logistics of matching people with sections of the code. I could see something working where on a 6-month basis, each of the main areas in
yt are
assigned a lead. That lead isn't necessarily the person who has written the most in the area, but rather a person who is willing to keep track of
area of the codebase for the next 6 months, so that when it comes to doing releases, they are the ones that know what has changed and where
not working well. Maybe that's too much of a process, but I also
should be wary of assigning potentially long-lasting labels to either
or code. Semi-regular meetings for this set of people would be great.
Anyways, I'm definitely a +1 on a YTEP for all of this, and look forward to hearing more!
Cheers, Sam
On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller
wrote: +1, absolutely. Right now, yt has a really high bus factor. I think this would help that a lot.
On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone <
chris.m.malone@gmail.com>
wrote:
+1 as well on all suggestions
> On Aug 15, 2014, at 5:32 PM, Kenza Arraki
wrote:
> > I wanted to put my strong +1 out there even though I don't respond > often to dev emails. This sounds like a great direction for yt! > > -Kenza > > --- > Kenza Arraki > PhD candidate > New Mexico State University > Department of Astronomy > > > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale >
wrote: >> these all sound like good ideas to me. Some simply operating >> procedures, >> like "don't merge your own pull requests" might be good too. >> >> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith >> >> wrote: >>> >>> I'm very in favor of putting some official procedures into a YTEP. >>> Having >>> a codified process may also help with conflict resolution as well. >>> >>> Apache does something with their projects where developers who make >>> sustained contribution are made "members" after nomination by >>> another member >>> and are given write access to the main repo. It's a small thing, >>> but if we >>> perhaps have an official definition of "yt member" in a YTEP with a >>> posted >>> list of members, it can be something people can point to as a way >>> of >>> demonstrating that they've done significant work on the project. >>> >>> I think it might also be good to have officer-like positions where >>> people >>> are representatives for various areas of the code, such as data >>> structures, >>> visualization, analysis_modules, etc. and to have semi-regular >>> meeting of >>> these people. This may be as much leadership as we need for now, >>> just a >>> group that meets on a schedule to make sure everyone's on the same >>> page with >>> releases and major development efforts. >>> >>> What do people think of something like this? >>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk >>> >>> wrote: >>>> >>>> Hi Britton, >>>> >>>> Thanks for bringing this up -- it's a tough topic, but also I >>>> think >>>> really important. At the WSSSPE conference last year, a paper was >>>> submitted talking about the Apache model: >>>> >>>> >>>> >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... >>>> >>>> which talks about a lot of related topics. Apache does some >>>> interesting things. They use the word "meritocracy" which I am >>>> rather >>>> -1 on using (see, for instance, >>>> >>>> >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... >>>> ) but I do think there is something to be said for a large part of >>>> their methods of organization. >>>> >>>> Like you, I think we are overdue. I would like to point out >>>> for >>>> all intents and purposes, you are *already* the ombudsman for
>>>> yt >>>> community. I don't think you're proposing we have a committee >>>> that >>>> bosses everyone around, but rather one that enables a larger >>>> number of >>>> people to have a say, particularly because yt has become embedded >>>> in >>>> many of our scientific workflows and it touches a lot of research >>>> activities now. I like the idea of members. I like the idea of a >>>> project management committee, but it's not clear to me how that >>>> would >>>> work, or which decisions we have made recently that they would >>>> weigh >>>> in on. I also really like the idea of having "code liasons" to >>>> different data platforms and/or communities, and the idea of >>>> having >>>> people who are responsible for many different areas of the code >>>> and >>>> codifying that in some way is quite attractive to me. >>>> >>>> For what it's worth, a few weeks ago I gave a presentation on my >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). The
>>>> is, >>>> while I gave this presentation, it's just *my* vision -- it is not >>>> necessarily anyone else's vision. And I think it's time we have >>>> some >>>> method of taking into account a diverse set of opinions for what >>>> we as >>>> a community can emphasize, how we resolve conflicts, and so on and >>>> so >>>> forth. >>>> >>>> Again, thanks for bringing this up. We need to have this >>>> conversation. >>>> >>>> -Matt >>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith >>>>
>>>> wrote: >>>>> Greeting yt developers, >>>>> >>>>> First, I want to congratulate everyone here on the successful >>>>> release >>>>> of yt-3.0. This was a massive effort on the part of so many and >>>>> a >>>>> true testament to the strength of this team. >>>>> >>>>> At the time of writing this, there are 78 members of the yt-dev >>>>> mailing list. As someone who does most of their work in very >>>>> small >>>>> collaborations, this amazes me and make me very proud. In case >>>>> you're >>>>> wondering, the yt-users list has 268 members. >>>>> >>>>> As a project, yt has a significant amount of infrastructure: code >>>>> review with pull requests, issue tracking, automated testing, >>>>> emails >>>>> lists, an IRC channel, enhancement proposals, workshops. All of >>>>> this >>>>> is evidence of our legitimacy as a Real Thing. However, one big >>>>> missing piece is a system of governance. I don't know exactly >>>>> what >>>>> this means, but I have some ideas, which I will share below. >>>>> What I >>>>> want to do right now is to start a discussion that will, >>>>> hopefully, >>>>> include as many people as possible on this list. >>>>> >>>>> For me, governance means (roughly) the following: >>>>> >>>>> - a set of procedures in writing for how various things are to be >>>>> done, such as acceptance of pull requests, releases, designating >>>>> developers as core contributors, etc. >>>>> >>>>> - a governing body to make decisions and help guide the >>>>> >>>>> This accomplishes a number of things, which as a project I
>>>>> we >>>>> need, such as: >>>>> >>>>> - overall stability of the project. >>>>> >>>>> - providing a system for conflict resolution. >>>>> >>>>> - maintaining the spirit of yt as a team effort. >>>>> >>>>> - providing a way for active contributors to get credit for
code. I that things are think we people that, the thing project. think their
>>>>> contribution in the form of official recognition. >>>>> >>>>> >>>>> So, these are my initial thoughts, but I really think this >>>>> deserves a >>>>> thorough discussion with as many people participating as >>>>> possible. >>>>> Please, think about what governance means to you, whether we need >>>>> it, >>>>> what it should be, and what we might get out of it, and share >>>>> your >>>>> thoughts over the next few days. I look forward to this >>>>> discussion. >>>>> >>>>> Britton >>>>> >>>>> >>>>> _______________________________________________ >>>>> yt-dev mailing list >>>>> yt-dev@lists.spacepope.org >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>> _______________________________________________ >>>> yt-dev mailing list >>>> yt-dev@lists.spacepope.org >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >>> >>> >>> _______________________________________________ >>> yt-dev mailing list >>> yt-dev@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >> >> -- >> Michael Zingale >> Associate Professor >> >> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, >> NY >> 11794-3800 >> phone: 631-632-8225 >> e-mail: Michael.Zingale@stonybrook.edu >> web: http://www.astro.sunysb.edu/mzingale >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi folks,
Chiming in as somebody who is on the far periphery of yt development
(having only contributed a couple of bug fixes/minor updates), I think that
creation of a formal governance structure is a significant positive step.
Given the distributed nature of the development team some level of
coordination is critical, and I also think that having a set of
carefully-considered standards about who gets a vote in terms of code
direction, and how many of these votes are needed to enact substantial
change (as opposed to the ad-hoc "preponderance of +1s from the mailing
list" method) is an exceedingly good idea, as it will hopefully enhance the
group's decision-making and make it more reflective.
I also want to comment on the monthly team meetings. In addition to
posting meeting minutes, perhaps the meeting coordinator or secretary could
organize an agenda for the meeting and post it to the yt-dev mailing list a
couple of days ahead of time? That way, people who are not participating
in the meeting, but who may have some input on the issues at hand, have an
opportunity to email suggestions.
Finally, one other point: I can't help but notice that while the technical
aspects of yt will be represented in these team meetings, there is no
*explicit* representation of the yt user community or yt documentation.
While in principle this isn't a problem -- Matt has made the point many
times that the difference between user and developer isn't necessarily
meaningful in our context -- I do think that having somebody involved whose
explicit responsibility is to consider the questions "how will this impact
the broader yt user community?" and "what's missing from the documentation
that could be added or improved?" may be beneficial.
Anyway, small nit-picks aside, I think this is a great idea. Thanks to
Britton for starting the ball rolling!
--Brian
On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk
Hi Britton,
I think this is really, really important, and I'm really happy with the YTEP as it stands.
We've only gotten feedback from a few people. I think it's really important to get both positive and negative feedback from people on this -- even to the level of "geez, stop taking yourselves so seriously!" :) Do you think maybe an email to the yt-users mailing list would be productive? Or even directly writing to the people identified as "founding" members?
-Matt
Hi everyone,
I have just issued a pull request to the YTEP repository containing an initial draft of yt team guidelines. I encourage everyone to take a look at it and offer their feedback. In case you don't get the notification,
On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith
wrote: the PR can be viewed here:
https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras...
Britton
On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith
wrote: Hi Sam,
This is an excellent point. I think it's important not to overburden a single person by being forever responsible for a large chunk of the
also think it's good to give as many as are willing an opportunity to share the role. Perhaps there is a team of people or subcommittee that is responsible for figuring out who their representative is. This can be ironed out.
I think we've gotten enough positive response to start thinking about a YTEP that lays it all out. I will start something this week, ask for feedback, and we can all develop this together.
In the mean time, if you would still like to chime in on this discussion, please do so. Thanks, everyone.
Britton
On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman
wrote: Hi all,
Britton -- I really like these ideas, and I like the member level being defined as write access.
I'm a bit more concerned about the officers designation in terms of the logistics of matching people with sections of the code. I could see something working where on a 6-month basis, each of the main areas in
yt are
assigned a lead. That lead isn't necessarily the person who has written the most in the area, but rather a person who is willing to keep track of
area of the codebase for the next 6 months, so that when it comes to doing releases, they are the ones that know what has changed and where
not working well. Maybe that's too much of a process, but I also
should be wary of assigning potentially long-lasting labels to either
or code. Semi-regular meetings for this set of people would be great.
Anyways, I'm definitely a +1 on a YTEP for all of this, and look forward to hearing more!
Cheers, Sam
On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller
wrote: +1, absolutely. Right now, yt has a really high bus factor. I think this would help that a lot.
On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone <
chris.m.malone@gmail.com>
wrote:
+1 as well on all suggestions
> On Aug 15, 2014, at 5:32 PM, Kenza Arraki
wrote:
> > I wanted to put my strong +1 out there even though I don't respond > often to dev emails. This sounds like a great direction for yt! > > -Kenza > > --- > Kenza Arraki > PhD candidate > New Mexico State University > Department of Astronomy > > > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale >
wrote: >> these all sound like good ideas to me. Some simply operating >> procedures, >> like "don't merge your own pull requests" might be good too. >> >> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith >> >> wrote: >>> >>> I'm very in favor of putting some official procedures into a YTEP. >>> Having >>> a codified process may also help with conflict resolution as well. >>> >>> Apache does something with their projects where developers who make >>> sustained contribution are made "members" after nomination by >>> another member >>> and are given write access to the main repo. It's a small thing, >>> but if we >>> perhaps have an official definition of "yt member" in a YTEP with a >>> posted >>> list of members, it can be something people can point to as a way >>> of >>> demonstrating that they've done significant work on the project. >>> >>> I think it might also be good to have officer-like positions where >>> people >>> are representatives for various areas of the code, such as data >>> structures, >>> visualization, analysis_modules, etc. and to have semi-regular >>> meeting of >>> these people. This may be as much leadership as we need for now, >>> just a >>> group that meets on a schedule to make sure everyone's on the same >>> page with >>> releases and major development efforts. >>> >>> What do people think of something like this? >>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk >>> >>> wrote: >>>> >>>> Hi Britton, >>>> >>>> Thanks for bringing this up -- it's a tough topic, but also I >>>> think >>>> really important. At the WSSSPE conference last year, a paper was >>>> submitted talking about the Apache model: >>>> >>>> >>>> >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... >>>> >>>> which talks about a lot of related topics. Apache does some >>>> interesting things. They use the word "meritocracy" which I am >>>> rather >>>> -1 on using (see, for instance, >>>> >>>> >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... >>>> ) but I do think there is something to be said for a large part of >>>> their methods of organization. >>>> >>>> Like you, I think we are overdue. I would like to point out >>>> for >>>> all intents and purposes, you are *already* the ombudsman for
>>>> yt >>>> community. I don't think you're proposing we have a committee >>>> that >>>> bosses everyone around, but rather one that enables a larger >>>> number of >>>> people to have a say, particularly because yt has become embedded >>>> in >>>> many of our scientific workflows and it touches a lot of research >>>> activities now. I like the idea of members. I like the idea of a >>>> project management committee, but it's not clear to me how that >>>> would >>>> work, or which decisions we have made recently that they would >>>> weigh >>>> in on. I also really like the idea of having "code liasons" to >>>> different data platforms and/or communities, and the idea of >>>> having >>>> people who are responsible for many different areas of the code >>>> and >>>> codifying that in some way is quite attractive to me. >>>> >>>> For what it's worth, a few weeks ago I gave a presentation on my >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). The
>>>> is, >>>> while I gave this presentation, it's just *my* vision -- it is not >>>> necessarily anyone else's vision. And I think it's time we have >>>> some >>>> method of taking into account a diverse set of opinions for what >>>> we as >>>> a community can emphasize, how we resolve conflicts, and so on and >>>> so >>>> forth. >>>> >>>> Again, thanks for bringing this up. We need to have this >>>> conversation. >>>> >>>> -Matt >>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith >>>>
>>>> wrote: >>>>> Greeting yt developers, >>>>> >>>>> First, I want to congratulate everyone here on the successful >>>>> release >>>>> of yt-3.0. This was a massive effort on the part of so many and >>>>> a >>>>> true testament to the strength of this team. >>>>> >>>>> At the time of writing this, there are 78 members of the yt-dev >>>>> mailing list. As someone who does most of their work in very >>>>> small >>>>> collaborations, this amazes me and make me very proud. In case >>>>> you're >>>>> wondering, the yt-users list has 268 members. >>>>> >>>>> As a project, yt has a significant amount of infrastructure: code >>>>> review with pull requests, issue tracking, automated testing, >>>>> emails >>>>> lists, an IRC channel, enhancement proposals, workshops. All of >>>>> this >>>>> is evidence of our legitimacy as a Real Thing. However, one big >>>>> missing piece is a system of governance. I don't know exactly >>>>> what >>>>> this means, but I have some ideas, which I will share below. >>>>> What I >>>>> want to do right now is to start a discussion that will, >>>>> hopefully, >>>>> include as many people as possible on this list. >>>>> >>>>> For me, governance means (roughly) the following: >>>>> >>>>> - a set of procedures in writing for how various things are to be >>>>> done, such as acceptance of pull requests, releases, designating >>>>> developers as core contributors, etc. >>>>> >>>>> - a governing body to make decisions and help guide the >>>>> >>>>> This accomplishes a number of things, which as a project I
>>>>> we >>>>> need, such as: >>>>> >>>>> - overall stability of the project. >>>>> >>>>> - providing a system for conflict resolution. >>>>> >>>>> - maintaining the spirit of yt as a team effort. >>>>> >>>>> - providing a way for active contributors to get credit for
code. I that things are think we people that, the thing project. think their
>>>>> contribution in the form of official recognition. >>>>> >>>>> >>>>> So, these are my initial thoughts, but I really think this >>>>> deserves a >>>>> thorough discussion with as many people participating as >>>>> possible. >>>>> Please, think about what governance means to you, whether we need >>>>> it, >>>>> what it should be, and what we might get out of it, and share >>>>> your >>>>> thoughts over the next few days. I look forward to this >>>>> discussion. >>>>> >>>>> Britton >>>>> >>>>> >>>>> _______________________________________________ >>>>> yt-dev mailing list >>>>> yt-dev@lists.spacepope.org >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>> _______________________________________________ >>>> yt-dev mailing list >>>> yt-dev@lists.spacepope.org >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >>> >>> >>> _______________________________________________ >>> yt-dev mailing list >>> yt-dev@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >> >> -- >> Michael Zingale >> Associate Professor >> >> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, >> NY >> 11794-3800 >> phone: 631-632-8225 >> e-mail: Michael.Zingale@stonybrook.edu >> web: http://www.astro.sunysb.edu/mzingale >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Brian,
On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea
Hi folks,
Chiming in as somebody who is on the far periphery of yt development (having only contributed a couple of bug fixes/minor updates), I think that creation of a formal governance structure is a significant positive step. Given the distributed nature of the development team some level of coordination is critical, and I also think that having a set of carefully-considered standards about who gets a vote in terms of code direction, and how many of these votes are needed to enact substantial change (as opposed to the ad-hoc "preponderance of +1s from the mailing list" method) is an exceedingly good idea, as it will hopefully enhance the group's decision-making and make it more reflective.
I also want to comment on the monthly team meetings. In addition to posting meeting minutes, perhaps the meeting coordinator or secretary could organize an agenda for the meeting and post it to the yt-dev mailing list a couple of days ahead of time? That way, people who are not participating in the meeting, but who may have some input on the issues at hand, have an opportunity to email suggestions.
Finally, one other point: I can't help but notice that while the technical aspects of yt will be represented in these team meetings, there is no *explicit* representation of the yt user community or yt documentation. While in principle this isn't a problem -- Matt has made the point many times that the difference between user and developer isn't necessarily meaningful in our context -- I do think that having somebody involved whose explicit responsibility is to consider the questions "how will this impact the broader yt user community?" and "what's missing from the documentation that could be added or improved?" may be beneficial.
Yes, I agree. I actually have a few people I would submit as nominations for this role, but it seems to me it's certainly one that should be represented.
Anyway, small nit-picks aside, I think this is a great idea. Thanks to Britton for starting the ball rolling!
--Brian
On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk
wrote: Hi Britton,
I think this is really, really important, and I'm really happy with the YTEP as it stands.
We've only gotten feedback from a few people. I think it's really important to get both positive and negative feedback from people on this -- even to the level of "geez, stop taking yourselves so seriously!" :) Do you think maybe an email to the yt-users mailing list would be productive? Or even directly writing to the people identified as "founding" members?
-Matt
On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith
wrote: Hi everyone,
I have just issued a pull request to the YTEP repository containing an initial draft of yt team guidelines. I encourage everyone to take a look at it and offer their feedback. In case you don't get the notification, the PR can be viewed here:
https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras...
Britton
On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith
wrote: Hi Sam,
This is an excellent point. I think it's important not to overburden a single person by being forever responsible for a large chunk of the code. I also think it's good to give as many as are willing an opportunity to share the role. Perhaps there is a team of people or subcommittee that is responsible for figuring out who their representative is. This can be ironed out.
I think we've gotten enough positive response to start thinking about a YTEP that lays it all out. I will start something this week, ask for feedback, and we can all develop this together.
In the mean time, if you would still like to chime in on this discussion, please do so. Thanks, everyone.
Britton
On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman
wrote: Hi all,
Britton -- I really like these ideas, and I like the member level being defined as write access.
I'm a bit more concerned about the officers designation in terms of the logistics of matching people with sections of the code. I could see something working where on a 6-month basis, each of the main areas in yt are assigned a lead. That lead isn't necessarily the person who has written the most in the area, but rather a person who is willing to keep track of that area of the codebase for the next 6 months, so that when it comes to doing releases, they are the ones that know what has changed and where things are not working well. Maybe that's too much of a process, but I also think we should be wary of assigning potentially long-lasting labels to either people or code. Semi-regular meetings for this set of people would be great.
Anyways, I'm definitely a +1 on a YTEP for all of this, and look forward to hearing more!
Cheers, Sam
On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller
wrote: +1, absolutely. Right now, yt has a really high bus factor. I think this would help that a lot.
On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone
wrote: > > +1 as well on all suggestions > > > On Aug 15, 2014, at 5:32 PM, Kenza Arraki > > wrote: > > > > I wanted to put my strong +1 out there even though I don't respond > > often to dev emails. This sounds like a great direction for yt! > > > > -Kenza > > > > --- > > Kenza Arraki > > PhD candidate > > New Mexico State University > > Department of Astronomy > > > > > > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale > > wrote: > >> these all sound like good ideas to me. Some simply operating > >> procedures, > >> like "don't merge your own pull requests" might be good too. > >> > >> > >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith > >> > >> wrote: > >>> > >>> I'm very in favor of putting some official procedures into a > >>> YTEP. > >>> Having > >>> a codified process may also help with conflict resolution as > >>> well. > >>> > >>> Apache does something with their projects where developers who > >>> make > >>> sustained contribution are made "members" after nomination by > >>> another member > >>> and are given write access to the main repo. It's a small > >>> thing, > >>> but if we > >>> perhaps have an official definition of "yt member" in a YTEP > >>> with a > >>> posted > >>> list of members, it can be something people can point to as a > >>> way > >>> of > >>> demonstrating that they've done significant work on the project. > >>> > >>> I think it might also be good to have officer-like positions > >>> where > >>> people > >>> are representatives for various areas of the code, such as data > >>> structures, > >>> visualization, analysis_modules, etc. and to have semi-regular > >>> meeting of > >>> these people. This may be as much leadership as we need for > >>> now, > >>> just a > >>> group that meets on a schedule to make sure everyone's on the > >>> same > >>> page with > >>> releases and major development efforts. > >>> > >>> What do people think of something like this? > >>> > >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk > >>> > >>> wrote: > >>>> > >>>> Hi Britton, > >>>> > >>>> Thanks for bringing this up -- it's a tough topic, but also I > >>>> think > >>>> really important. At the WSSSPE conference last year, a paper > >>>> was > >>>> submitted talking about the Apache model: > >>>> > >>>> > >>>> > >>>> > >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... > >>>> > >>>> which talks about a lot of related topics. Apache does some > >>>> interesting things. They use the word "meritocracy" which I am > >>>> rather > >>>> -1 on using (see, for instance, > >>>> > >>>> > >>>> > >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... > >>>> ) but I do think there is something to be said for a large part > >>>> of > >>>> their methods of organization. > >>>> > >>>> Like you, I think we are overdue. I would like to point out > >>>> that, > >>>> for > >>>> all intents and purposes, you are *already* the ombudsman for > >>>> the > >>>> yt > >>>> community. I don't think you're proposing we have a committee > >>>> that > >>>> bosses everyone around, but rather one that enables a larger > >>>> number of > >>>> people to have a say, particularly because yt has become > >>>> embedded > >>>> in > >>>> many of our scientific workflows and it touches a lot of > >>>> research > >>>> activities now. I like the idea of members. I like the idea > >>>> of a > >>>> project management committee, but it's not clear to me how that > >>>> would > >>>> work, or which decisions we have made recently that they would > >>>> weigh > >>>> in on. I also really like the idea of having "code liasons" to > >>>> different data platforms and/or communities, and the idea of > >>>> having > >>>> people who are responsible for many different areas of the code > >>>> and > >>>> codifying that in some way is quite attractive to me. > >>>> > >>>> For what it's worth, a few weeks ago I gave a presentation on > >>>> my > >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). The > >>>> thing > >>>> is, > >>>> while I gave this presentation, it's just *my* vision -- it is > >>>> not > >>>> necessarily anyone else's vision. And I think it's time we > >>>> have > >>>> some > >>>> method of taking into account a diverse set of opinions for > >>>> what > >>>> we as > >>>> a community can emphasize, how we resolve conflicts, and so on > >>>> and > >>>> so > >>>> forth. > >>>> > >>>> Again, thanks for bringing this up. We need to have this > >>>> conversation. > >>>> > >>>> -Matt > >>>> > >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith > >>>> > >>>> wrote: > >>>>> Greeting yt developers, > >>>>> > >>>>> First, I want to congratulate everyone here on the successful > >>>>> release > >>>>> of yt-3.0. This was a massive effort on the part of so many > >>>>> and > >>>>> a > >>>>> true testament to the strength of this team. > >>>>> > >>>>> At the time of writing this, there are 78 members of the > >>>>> yt-dev > >>>>> mailing list. As someone who does most of their work in very > >>>>> small > >>>>> collaborations, this amazes me and make me very proud. In > >>>>> case > >>>>> you're > >>>>> wondering, the yt-users list has 268 members. > >>>>> > >>>>> As a project, yt has a significant amount of infrastructure: > >>>>> code > >>>>> review with pull requests, issue tracking, automated testing, > >>>>> emails > >>>>> lists, an IRC channel, enhancement proposals, workshops. All > >>>>> of > >>>>> this > >>>>> is evidence of our legitimacy as a Real Thing. However, one > >>>>> big > >>>>> missing piece is a system of governance. I don't know exactly > >>>>> what > >>>>> this means, but I have some ideas, which I will share below. > >>>>> What I > >>>>> want to do right now is to start a discussion that will, > >>>>> hopefully, > >>>>> include as many people as possible on this list. > >>>>> > >>>>> For me, governance means (roughly) the following: > >>>>> > >>>>> - a set of procedures in writing for how various things are to > >>>>> be > >>>>> done, such as acceptance of pull requests, releases, > >>>>> designating > >>>>> developers as core contributors, etc. > >>>>> > >>>>> - a governing body to make decisions and help guide the > >>>>> project. > >>>>> > >>>>> This accomplishes a number of things, which as a project I > >>>>> think > >>>>> we > >>>>> need, such as: > >>>>> > >>>>> - overall stability of the project. > >>>>> > >>>>> - providing a system for conflict resolution. > >>>>> > >>>>> - maintaining the spirit of yt as a team effort. > >>>>> > >>>>> - providing a way for active contributors to get credit for > >>>>> their > >>>>> contribution in the form of official recognition. > >>>>> > >>>>> > >>>>> So, these are my initial thoughts, but I really think this > >>>>> deserves a > >>>>> thorough discussion with as many people participating as > >>>>> possible. > >>>>> Please, think about what governance means to you, whether we > >>>>> need > >>>>> it, > >>>>> what it should be, and what we might get out of it, and share > >>>>> your > >>>>> thoughts over the next few days. I look forward to this > >>>>> discussion. > >>>>> > >>>>> Britton > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> yt-dev mailing list > >>>>> yt-dev@lists.spacepope.org > >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>>> _______________________________________________ > >>>> yt-dev mailing list > >>>> yt-dev@lists.spacepope.org > >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> > >>> > >>> > >>> _______________________________________________ > >>> yt-dev mailing list > >>> yt-dev@lists.spacepope.org > >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> > >> > >> > >> -- > >> Michael Zingale > >> Associate Professor > >> > >> Dept. of Physics & Astronomy • Stony Brook University • Stony > >> Brook, > >> NY > >> 11794-3800 > >> phone: 631-632-8225 > >> e-mail: Michael.Zingale@stonybrook.edu > >> web: http://www.astro.sunysb.edu/mzingale > >> > >> _______________________________________________ > >> yt-dev mailing list > >> yt-dev@lists.spacepope.org > >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > _______________________________________________ > > yt-dev mailing list > > yt-dev@lists.spacepope.org > > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
HI Brian,
I couldn't agree more on having a documentation representative present at
team meetings. In fact, I think this was even in my original draft, but I
somehow lost track of it. Thanks for bringing it up. I will get that back
in there. A community representative is also a good idea, but I'm less
sure how that role would be filled. If anyone has any thoughts on that,
please do share. If it can't be figured out before the YTEP is accepted,
we can definitely amend it. Thanks, Brian!
Britton
On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk
Hi Brian,
Hi folks,
Chiming in as somebody who is on the far periphery of yt development (having only contributed a couple of bug fixes/minor updates), I think that creation of a formal governance structure is a significant positive step. Given
distributed nature of the development team some level of coordination is critical, and I also think that having a set of carefully-considered standards about who gets a vote in terms of code direction, and how many of these votes are needed to enact substantial change (as opposed to the ad-hoc "preponderance of +1s from the mailing list" method) is an exceedingly good idea, as it will hopefully enhance the group's decision-making and make it more reflective.
I also want to comment on the monthly team meetings. In addition to
On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea
wrote: the posting meeting minutes, perhaps the meeting coordinator or secretary could organize an agenda for the meeting and post it to the yt-dev mailing list a couple of days ahead of time? That way, people who are not participating in the meeting, but who may have some input on the issues at hand, have an opportunity to email suggestions.
Finally, one other point: I can't help but notice that while the technical aspects of yt will be represented in these team meetings, there is no *explicit* representation of the yt user community or yt documentation. While in principle this isn't a problem -- Matt has made the point many times that the difference between user and developer isn't necessarily meaningful in our context -- I do think that having somebody involved whose explicit responsibility is to consider the questions "how will this impact the broader yt user community?" and "what's missing from the documentation that could be added or improved?" may be beneficial.
Yes, I agree. I actually have a few people I would submit as nominations for this role, but it seems to me it's certainly one that should be represented.
Anyway, small nit-picks aside, I think this is a great idea. Thanks to Britton for starting the ball rolling!
--Brian
On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk
Hi Britton,
I think this is really, really important, and I'm really happy with the YTEP as it stands.
We've only gotten feedback from a few people. I think it's really important to get both positive and negative feedback from people on this -- even to the level of "geez, stop taking yourselves so seriously!" :) Do you think maybe an email to the yt-users mailing list would be productive? Or even directly writing to the people identified as "founding" members?
-Matt
On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith
wrote: Hi everyone,
I have just issued a pull request to the YTEP repository containing an initial draft of yt team guidelines. I encourage everyone to take a look at it and offer their feedback. In case you don't get the notification, the PR can be viewed here:
https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras...
Britton
On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith <
brittonsmith@gmail.com>
wrote:
Hi Sam,
This is an excellent point. I think it's important not to
overburden a
single person by being forever responsible for a large chunk of the code. I also think it's good to give as many as are willing an opportunity to share the role. Perhaps there is a team of people or subcommittee that is responsible for figuring out who their representative is. This can be ironed out.
I think we've gotten enough positive response to start thinking about a YTEP that lays it all out. I will start something this week, ask for feedback, and we can all develop this together.
In the mean time, if you would still like to chime in on this discussion, please do so. Thanks, everyone.
Britton
On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman
wrote:
Hi all,
Britton -- I really like these ideas, and I like the member level being defined as write access.
I'm a bit more concerned about the officers designation in terms of the logistics of matching people with sections of the code. I could see something working where on a 6-month basis, each of the main areas
in
yt are assigned a lead. That lead isn't necessarily the person who has written the most in the area, but rather a person who is willing to keep track of that area of the codebase for the next 6 months, so that when it comes to doing releases, they are the ones that know what has changed and where things are not working well. Maybe that's too much of a process, but I also think we should be wary of assigning potentially long-lasting labels to either people or code. Semi-regular meetings for this set of people would be great.
Anyways, I'm definitely a +1 on a YTEP for all of this, and look forward to hearing more!
Cheers, Sam
On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller
wrote: > > +1, absolutely. Right now, yt has a really high bus factor. I > this would help that a lot. > > > On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone >
> wrote: >> >> +1 as well on all suggestions >> >> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki >> > wrote: >> > >> > I wanted to put my strong +1 out there even though I don't respond >> > often to dev emails. This sounds like a great direction for yt! >> > >> > -Kenza >> > >> > --- >> > Kenza Arraki >> > PhD candidate >> > New Mexico State University >> > Department of Astronomy >> > >> > >> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale >> > wrote: >> >> these all sound like good ideas to me. Some simply operating >> >> procedures, >> >> like "don't merge your own pull requests" might be good too. >> >> >> >> >> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith >> >> >> >> wrote: >> >>> >> >>> I'm very in favor of putting some official procedures into a >> >>> YTEP. >> >>> Having >> >>> a codified process may also help with conflict resolution as >> >>> well. >> >>> >> >>> Apache does something with their projects where developers who >> >>> make >> >>> sustained contribution are made "members" after nomination by >> >>> another member >> >>> and are given write access to the main repo. It's a small >> >>> thing, >> >>> but if we >> >>> perhaps have an official definition of "yt member" in a YTEP >> >>> with a >> >>> posted >> >>> list of members, it can be something people can point to as a >> >>> way >> >>> of >> >>> demonstrating that they've done significant work on the >> >>> >> >>> I think it might also be good to have officer-like positions >> >>> where >> >>> people >> >>> are representatives for various areas of the code, such as data >> >>> structures, >> >>> visualization, analysis_modules, etc. and to have semi-regular >> >>> meeting of >> >>> these people. This may be as much leadership as we need for >> >>> now, >> >>> just a >> >>> group that meets on a schedule to make sure everyone's on the >> >>> same >> >>> page with >> >>> releases and major development efforts. >> >>> >> >>> What do people think of something like this? >> >>> >> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk >> >>>
>> >>> wrote: >> >>>> >> >>>> Hi Britton, >> >>>> >> >>>> Thanks for bringing this up -- it's a tough topic, but also I >> >>>> think >> >>>> really important. At the WSSSPE conference last year, a >> >>>> was >> >>>> submitted talking about the Apache model: >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... >> >>>> >> >>>> which talks about a lot of related topics. Apache does some >> >>>> interesting things. They use the word "meritocracy" which I am >> >>>> rather >> >>>> -1 on using (see, for instance, >> >>>> >> >>>> >> >>>> >> >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... >> >>>> ) but I do think there is something to be said for a large
>> >>>> of >> >>>> their methods of organization. >> >>>> >> >>>> Like you, I think we are overdue. I would like to point out >> >>>> that, >> >>>> for >> >>>> all intents and purposes, you are *already* the ombudsman for >> >>>> the >> >>>> yt >> >>>> community. I don't think you're proposing we have a committee >> >>>> that >> >>>> bosses everyone around, but rather one that enables a larger >> >>>> number of >> >>>> people to have a say, particularly because yt has become >> >>>> embedded >> >>>> in >> >>>> many of our scientific workflows and it touches a lot of >> >>>> research >> >>>> activities now. I like the idea of members. I like the idea >> >>>> of a >> >>>> project management committee, but it's not clear to me how
wrote: think project. paper part that
>> >>>> would >> >>>> work, or which decisions we have made recently that they would >> >>>> weigh >> >>>> in on. I also really like the idea of having "code liasons" to >> >>>> different data platforms and/or communities, and the idea of >> >>>> having >> >>>> people who are responsible for many different areas of the code >> >>>> and >> >>>> codifying that in some way is quite attractive to me. >> >>>> >> >>>> For what it's worth, a few weeks ago I gave a presentation on >> >>>> my >> >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). The >> >>>> thing >> >>>> is, >> >>>> while I gave this presentation, it's just *my* vision -- it is >> >>>> not >> >>>> necessarily anyone else's vision. And I think it's time we >> >>>> have >> >>>> some >> >>>> method of taking into account a diverse set of opinions for >> >>>> what >> >>>> we as >> >>>> a community can emphasize, how we resolve conflicts, and so on >> >>>> and >> >>>> so >> >>>> forth. >> >>>> >> >>>> Again, thanks for bringing this up. We need to have this >> >>>> conversation. >> >>>> >> >>>> -Matt >> >>>> >> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith >> >>>>
>> >>>> wrote: >> >>>>> Greeting yt developers, >> >>>>> >> >>>>> First, I want to congratulate everyone here on the successful >> >>>>> release >> >>>>> of yt-3.0. This was a massive effort on the part of so many >> >>>>> and >> >>>>> a >> >>>>> true testament to the strength of this team. >> >>>>> >> >>>>> At the time of writing this, there are 78 members of the >> >>>>> yt-dev >> >>>>> mailing list. As someone who does most of their work in very >> >>>>> small >> >>>>> collaborations, this amazes me and make me very proud. In >> >>>>> case >> >>>>> you're >> >>>>> wondering, the yt-users list has 268 members. >> >>>>> >> >>>>> As a project, yt has a significant amount of infrastructure: >> >>>>> code >> >>>>> review with pull requests, issue tracking, automated testing, >> >>>>> emails >> >>>>> lists, an IRC channel, enhancement proposals, workshops. All >> >>>>> of >> >>>>> this >> >>>>> is evidence of our legitimacy as a Real Thing. However, one >> >>>>> big >> >>>>> missing piece is a system of governance. I don't know exactly >> >>>>> what >> >>>>> this means, but I have some ideas, which I will share below. >> >>>>> What I >> >>>>> want to do right now is to start a discussion that will, >> >>>>> hopefully, >> >>>>> include as many people as possible on this list. >> >>>>> >> >>>>> For me, governance means (roughly) the following: >> >>>>> >> >>>>> - a set of procedures in writing for how various things are to >> >>>>> be >> >>>>> done, such as acceptance of pull requests, releases, >> >>>>> designating >> >>>>> developers as core contributors, etc. >> >>>>> >> >>>>> - a governing body to make decisions and help guide the >> >>>>> project. >> >>>>> >> >>>>> This accomplishes a number of things, which as a project I >> >>>>> think >> >>>>> we >> >>>>> need, such as: >> >>>>> >> >>>>> - overall stability of the project. >> >>>>> >> >>>>> - providing a system for conflict resolution. >> >>>>> >> >>>>> - maintaining the spirit of yt as a team effort. >> >>>>> >> >>>>> - providing a way for active contributors to get credit for >> >>>>> their >> >>>>> contribution in the form of official recognition. >> >>>>> >> >>>>> >> >>>>> So, these are my initial thoughts, but I really think this >> >>>>> deserves a >> >>>>> thorough discussion with as many people participating as >> >>>>> possible. >> >>>>> Please, think about what governance means to you, whether we >> >>>>> need >> >>>>> it, >> >>>>> what it should be, and what we might get out of it, and share >> >>>>> your >> >>>>> thoughts over the next few days. I look forward to this >> >>>>> discussion. >> >>>>> >> >>>>> Britton >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> yt-dev mailing list >> >>>>> yt-dev@lists.spacepope.org >> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>>> _______________________________________________ >> >>>> yt-dev mailing list >> >>>> yt-dev@lists.spacepope.org >> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> yt-dev mailing list >> >>> yt-dev@lists.spacepope.org >> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >> >> >> >> >> >> -- >> >> Michael Zingale >> >> Associate Professor >> >> >> >> Dept. of Physics & Astronomy • Stony Brook University • Stony >> >> Brook, >> >> NY >> >> 11794-3800 >> >> phone: 631-632-8225 >> >> e-mail: Michael.Zingale@stonybrook.edu >> >> web: http://www.astro.sunysb.edu/mzingale >> >> >> >> _______________________________________________ >> >> yt-dev mailing list >> >> yt-dev@lists.spacepope.org >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > _______________________________________________ >> > yt-dev mailing list >> > yt-dev@lists.spacepope.org >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Britton,
No worries - I also don't quite know what a community representative's role
would look like either, and it may simply be that it's something that the
meeting organizer needs to be sure to bring up a lot.
After thinking about it a bit, I realized that ultimately my concern is
that the people involved in the team meetings are (essentially by
definition) going to be the most active yt developers, and thus those yt
*users* that are most comfortable with large and/or frequent changes to yt
and its interface, due to their nature and also to the fact that they're
paying close attention to the development process. This comfort level
means that significant changes don't feel like as big of a deal to them,
and thus they're more likely to sign off on them (which is not necessarily
a bad thing). Users that are more removed from the development process and
less comfortable with code and code development (undergrad research
students, for example) have a much more challenging time dealing with these
major changes (the yt 2.x->3.x transition), and a great deal of
productivity is lost that could probably be avoided.
By the way, I realize that sounds like a condemnation of the yt development
process, and I assure you that I don't intend it to be. Given how much the
user base of yt has grown, and how much its functionality, portability, and
scalability has increased over the last handful of years, some growing
pains are inevitable. As the code continues to mature and the user
community grows, there will be a larger proportion of computationally
less-sophisticated users, though - so let's be as kind to them as possible!
Brian
On Sat, Aug 30, 2014 at 9:30 AM, Britton Smith
HI Brian,
I couldn't agree more on having a documentation representative present at team meetings. In fact, I think this was even in my original draft, but I somehow lost track of it. Thanks for bringing it up. I will get that back in there. A community representative is also a good idea, but I'm less sure how that role would be filled. If anyone has any thoughts on that, please do share. If it can't be figured out before the YTEP is accepted, we can definitely amend it. Thanks, Brian!
Britton
On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk
wrote: Hi Brian,
Hi folks,
Chiming in as somebody who is on the far periphery of yt development (having only contributed a couple of bug fixes/minor updates), I think that creation of a formal governance structure is a significant positive step. Given
distributed nature of the development team some level of coordination is critical, and I also think that having a set of carefully-considered standards about who gets a vote in terms of code direction, and how many of these votes are needed to enact substantial change (as opposed to the ad-hoc "preponderance of +1s from the mailing list" method) is an exceedingly good idea, as it will hopefully enhance the group's decision-making and make it more reflective.
I also want to comment on the monthly team meetings. In addition to
On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea
wrote: the posting meeting minutes, perhaps the meeting coordinator or secretary could organize an agenda for the meeting and post it to the yt-dev mailing list a couple of days ahead of time? That way, people who are not participating in the meeting, but who may have some input on the issues at hand, have an opportunity to email suggestions.
Finally, one other point: I can't help but notice that while the technical aspects of yt will be represented in these team meetings, there is no *explicit* representation of the yt user community or yt documentation. While in principle this isn't a problem -- Matt has made the point many times that the difference between user and developer isn't necessarily meaningful in our context -- I do think that having somebody involved whose explicit responsibility is to consider the questions "how will this impact the broader yt user community?" and "what's missing from the documentation that could be added or improved?" may be beneficial.
Yes, I agree. I actually have a few people I would submit as nominations for this role, but it seems to me it's certainly one that should be represented.
Anyway, small nit-picks aside, I think this is a great idea. Thanks to Britton for starting the ball rolling!
--Brian
On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk
Hi Britton,
I think this is really, really important, and I'm really happy with the YTEP as it stands.
We've only gotten feedback from a few people. I think it's really important to get both positive and negative feedback from people on this -- even to the level of "geez, stop taking yourselves so seriously!" :) Do you think maybe an email to the yt-users mailing list would be productive? Or even directly writing to the people identified as "founding" members?
-Matt
On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith
wrote:
Hi everyone,
I have just issued a pull request to the YTEP repository containing an initial draft of yt team guidelines. I encourage everyone to take a look at it and offer their feedback. In case you don't get the notification, the PR can be viewed here:
https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras...
Britton
On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith <
brittonsmith@gmail.com>
wrote:
Hi Sam,
This is an excellent point. I think it's important not to
overburden a
single person by being forever responsible for a large chunk of the code. I also think it's good to give as many as are willing an opportunity to share the role. Perhaps there is a team of people or subcommittee that is responsible for figuring out who their representative is. This can be ironed out.
I think we've gotten enough positive response to start thinking about a YTEP that lays it all out. I will start something this week, ask for feedback, and we can all develop this together.
In the mean time, if you would still like to chime in on this discussion, please do so. Thanks, everyone.
Britton
On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman < samskillman@gmail.com> wrote: > > Hi all, > > Britton -- I really like these ideas, and I like the member level > being > defined as write access. > > I'm a bit more concerned about the officers designation in terms of > the > logistics of matching people with sections of the code. I could see > something working where on a 6-month basis, each of the main areas in > yt are > assigned a lead. That lead isn't necessarily the person who has > written the > most in the area, but rather a person who is willing to keep track of > that > area of the codebase for the next 6 months, so that when it comes to > doing > releases, they are the ones that know what has changed and where > things are > not working well. Maybe that's too much of a process, but I also > think we > should be wary of assigning potentially long-lasting labels to either > people > or code. Semi-regular meetings for this set of people would be great. > > Anyways, I'm definitely a +1 on a YTEP for all of this, and look > forward > to hearing more! > > Cheers, > Sam > > > On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller
> wrote: >> >> +1, absolutely. Right now, yt has a really high bus factor. I
>> this would help that a lot. >> >> >> On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone >>
>> wrote: >>> >>> +1 as well on all suggestions >>> >>> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki >>> > wrote: >>> > >>> > I wanted to put my strong +1 out there even though I don't respond >>> > often to dev emails. This sounds like a great direction for yt! >>> > >>> > -Kenza >>> > >>> > --- >>> > Kenza Arraki >>> > PhD candidate >>> > New Mexico State University >>> > Department of Astronomy >>> > >>> > >>> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale >>> > wrote: >>> >> these all sound like good ideas to me. Some simply operating >>> >> procedures, >>> >> like "don't merge your own pull requests" might be good too. >>> >> >>> >> >>> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith >>> >> >>> >> wrote: >>> >>> >>> >>> I'm very in favor of putting some official procedures into a >>> >>> YTEP. >>> >>> Having >>> >>> a codified process may also help with conflict resolution as >>> >>> well. >>> >>> >>> >>> Apache does something with their projects where developers who >>> >>> make >>> >>> sustained contribution are made "members" after nomination by >>> >>> another member >>> >>> and are given write access to the main repo. It's a small >>> >>> thing, >>> >>> but if we >>> >>> perhaps have an official definition of "yt member" in a YTEP >>> >>> with a >>> >>> posted >>> >>> list of members, it can be something people can point to as a >>> >>> way >>> >>> of >>> >>> demonstrating that they've done significant work on the >>> >>> >>> >>> I think it might also be good to have officer-like positions >>> >>> where >>> >>> people >>> >>> are representatives for various areas of the code, such as data >>> >>> structures, >>> >>> visualization, analysis_modules, etc. and to have semi-regular >>> >>> meeting of >>> >>> these people. This may be as much leadership as we need for >>> >>> now, >>> >>> just a >>> >>> group that meets on a schedule to make sure everyone's on the >>> >>> same >>> >>> page with >>> >>> releases and major development efforts. >>> >>> >>> >>> What do people think of something like this? >>> >>> >>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk >>> >>>
>>> >>> wrote: >>> >>>> >>> >>>> Hi Britton, >>> >>>> >>> >>>> Thanks for bringing this up -- it's a tough topic, but also I >>> >>>> think >>> >>>> really important. At the WSSSPE conference last year, a >>> >>>> was >>> >>>> submitted talking about the Apache model: >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... >>> >>>> >>> >>>> which talks about a lot of related topics. Apache does some >>> >>>> interesting things. They use the word "meritocracy" which I am >>> >>>> rather >>> >>>> -1 on using (see, for instance, >>> >>>> >>> >>>> >>> >>>> >>> >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... >>> >>>> ) but I do think there is something to be said for a large
>>> >>>> of >>> >>>> their methods of organization. >>> >>>> >>> >>>> Like you, I think we are overdue. I would like to point out >>> >>>> that, >>> >>>> for >>> >>>> all intents and purposes, you are *already* the ombudsman for >>> >>>> the >>> >>>> yt >>> >>>> community. I don't think you're proposing we have a committee >>> >>>> that >>> >>>> bosses everyone around, but rather one that enables a larger >>> >>>> number of >>> >>>> people to have a say, particularly because yt has become >>> >>>> embedded >>> >>>> in >>> >>>> many of our scientific workflows and it touches a lot of >>> >>>> research >>> >>>> activities now. I like the idea of members. I like the idea >>> >>>> of a >>> >>>> project management committee, but it's not clear to me how
>>> >>>> would >>> >>>> work, or which decisions we have made recently that they would >>> >>>> weigh >>> >>>> in on. I also really like the idea of having "code
wrote: think project. paper part that liasons" to
>>> >>>> different data platforms and/or communities, and the idea of >>> >>>> having >>> >>>> people who are responsible for many different areas of the code >>> >>>> and >>> >>>> codifying that in some way is quite attractive to me. >>> >>>> >>> >>>> For what it's worth, a few weeks ago I gave a presentation on >>> >>>> my >>> >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). The >>> >>>> thing >>> >>>> is, >>> >>>> while I gave this presentation, it's just *my* vision -- it is >>> >>>> not >>> >>>> necessarily anyone else's vision. And I think it's time we >>> >>>> have >>> >>>> some >>> >>>> method of taking into account a diverse set of opinions for >>> >>>> what >>> >>>> we as >>> >>>> a community can emphasize, how we resolve conflicts, and so on >>> >>>> and >>> >>>> so >>> >>>> forth. >>> >>>> >>> >>>> Again, thanks for bringing this up. We need to have this >>> >>>> conversation. >>> >>>> >>> >>>> -Matt >>> >>>> >>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith >>> >>>>
>>> >>>> wrote: >>> >>>>> Greeting yt developers, >>> >>>>> >>> >>>>> First, I want to congratulate everyone here on the successful >>> >>>>> release >>> >>>>> of yt-3.0. This was a massive effort on the part of so many >>> >>>>> and >>> >>>>> a >>> >>>>> true testament to the strength of this team. >>> >>>>> >>> >>>>> At the time of writing this, there are 78 members of the >>> >>>>> yt-dev >>> >>>>> mailing list. As someone who does most of their work in very >>> >>>>> small >>> >>>>> collaborations, this amazes me and make me very proud. In >>> >>>>> case >>> >>>>> you're >>> >>>>> wondering, the yt-users list has 268 members. >>> >>>>> >>> >>>>> As a project, yt has a significant amount of infrastructure: >>> >>>>> code >>> >>>>> review with pull requests, issue tracking, automated testing, >>> >>>>> emails >>> >>>>> lists, an IRC channel, enhancement proposals, workshops. All >>> >>>>> of >>> >>>>> this >>> >>>>> is evidence of our legitimacy as a Real Thing. However, one >>> >>>>> big >>> >>>>> missing piece is a system of governance. I don't know exactly >>> >>>>> what >>> >>>>> this means, but I have some ideas, which I will share below. >>> >>>>> What I >>> >>>>> want to do right now is to start a discussion that will, >>> >>>>> hopefully, >>> >>>>> include as many people as possible on this list. >>> >>>>> >>> >>>>> For me, governance means (roughly) the following: >>> >>>>> >>> >>>>> - a set of procedures in writing for how various things are to >>> >>>>> be >>> >>>>> done, such as acceptance of pull requests, releases, >>> >>>>> designating >>> >>>>> developers as core contributors, etc. >>> >>>>> >>> >>>>> - a governing body to make decisions and help guide the >>> >>>>> project. >>> >>>>> >>> >>>>> This accomplishes a number of things, which as a project I >>> >>>>> think >>> >>>>> we >>> >>>>> need, such as: >>> >>>>> >>> >>>>> - overall stability of the project. >>> >>>>> >>> >>>>> - providing a system for conflict resolution. >>> >>>>> >>> >>>>> - maintaining the spirit of yt as a team effort. >>> >>>>> >>> >>>>> - providing a way for active contributors to get credit for >>> >>>>> their >>> >>>>> contribution in the form of official recognition. >>> >>>>> >>> >>>>> >>> >>>>> So, these are my initial thoughts, but I really think this >>> >>>>> deserves a >>> >>>>> thorough discussion with as many people participating as >>> >>>>> possible. >>> >>>>> Please, think about what governance means to you, whether we >>> >>>>> need >>> >>>>> it, >>> >>>>> what it should be, and what we might get out of it, and share >>> >>>>> your >>> >>>>> thoughts over the next few days. I look forward to this >>> >>>>> discussion. >>> >>>>> >>> >>>>> Britton >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> yt-dev mailing list >>> >>>>> yt-dev@lists.spacepope.org >>> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >>>> _______________________________________________ >>> >>>> yt-dev mailing list >>> >>>> yt-dev@lists.spacepope.org >>> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> yt-dev mailing list >>> >>> yt-dev@lists.spacepope.org >>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> >>> >> >>> >> >>> >> -- >>> >> Michael Zingale >>> >> Associate Professor >>> >> >>> >> Dept. of Physics & Astronomy • Stony Brook University • Stony >>> >> Brook, >>> >> NY >>> >> 11794-3800 >>> >> phone: 631-632-8225 >>> >> e-mail: Michael.Zingale@stonybrook.edu >>> >> web: http://www.astro.sunysb.edu/mzingale >>> >> >>> >> _______________________________________________ >>> >> yt-dev mailing list >>> >> yt-dev@lists.spacepope.org >>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> > _______________________________________________ >>> > yt-dev mailing list >>> > yt-dev@lists.spacepope.org >>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> _______________________________________________ >>> yt-dev mailing list >>> yt-dev@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Sat, Aug 30, 2014 at 11:45 AM, Brian O'Shea
Hi Britton,
No worries - I also don't quite know what a community representative's role would look like either, and it may simply be that it's something that the meeting organizer needs to be sure to bring up a lot.
After thinking about it a bit, I realized that ultimately my concern is that the people involved in the team meetings are (essentially by definition) going to be the most active yt developers, and thus those yt *users* that are most comfortable with large and/or frequent changes to yt and its interface, due to their nature and also to the fact that they're paying close attention to the development process. This comfort level means that significant changes don't feel like as big of a deal to them, and thus they're more likely to sign off on them (which is not necessarily a bad thing). Users that are more removed from the development process and less comfortable with code and code development (undergrad research students, for example) have a much more challenging time dealing with these major changes (the yt 2.x->3.x transition), and a great deal of productivity is lost that could probably be avoided.
By the way, I realize that sounds like a condemnation of the yt development process, and I assure you that I don't intend it to be. Given how much the user base of yt has grown, and how much its functionality, portability, and scalability has increased over the last handful of years, some growing pains are inevitable. As the code continues to mature and the user community grows, there will be a larger proportion of computationally less-sophisticated users, though - so let's be as kind to them as possible!
I want to emphasize that the initial list of members Britton came up with (as he noted in the proposal) is only an *initial* list, and will hopefully very quickly expand to include less active "developers" who are nonetheless embedded in the community. -Matt
Brian
On Sat, Aug 30, 2014 at 9:30 AM, Britton Smith
wrote: HI Brian,
I couldn't agree more on having a documentation representative present at team meetings. In fact, I think this was even in my original draft, but I somehow lost track of it. Thanks for bringing it up. I will get that back in there. A community representative is also a good idea, but I'm less sure how that role would be filled. If anyone has any thoughts on that, please do share. If it can't be figured out before the YTEP is accepted, we can definitely amend it. Thanks, Brian!
Britton
On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk
wrote: Hi Brian,
On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea
wrote: Hi folks,
Chiming in as somebody who is on the far periphery of yt development (having only contributed a couple of bug fixes/minor updates), I think that creation of a formal governance structure is a significant positive step. Given the distributed nature of the development team some level of coordination is critical, and I also think that having a set of carefully-considered standards about who gets a vote in terms of code direction, and how many of these votes are needed to enact substantial change (as opposed to the ad-hoc "preponderance of +1s from the mailing list" method) is an exceedingly good idea, as it will hopefully enhance the group's decision-making and make it more reflective.
I also want to comment on the monthly team meetings. In addition to posting meeting minutes, perhaps the meeting coordinator or secretary could organize an agenda for the meeting and post it to the yt-dev mailing list a couple of days ahead of time? That way, people who are not participating in the meeting, but who may have some input on the issues at hand, have an opportunity to email suggestions.
Finally, one other point: I can't help but notice that while the technical aspects of yt will be represented in these team meetings, there is no *explicit* representation of the yt user community or yt documentation. While in principle this isn't a problem -- Matt has made the point many times that the difference between user and developer isn't necessarily meaningful in our context -- I do think that having somebody involved whose explicit responsibility is to consider the questions "how will this impact the broader yt user community?" and "what's missing from the documentation that could be added or improved?" may be beneficial.
Yes, I agree. I actually have a few people I would submit as nominations for this role, but it seems to me it's certainly one that should be represented.
Anyway, small nit-picks aside, I think this is a great idea. Thanks to Britton for starting the ball rolling!
--Brian
On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk
wrote: Hi Britton,
I think this is really, really important, and I'm really happy with the YTEP as it stands.
We've only gotten feedback from a few people. I think it's really important to get both positive and negative feedback from people on this -- even to the level of "geez, stop taking yourselves so seriously!" :) Do you think maybe an email to the yt-users mailing list would be productive? Or even directly writing to the people identified as "founding" members?
-Matt
On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith
wrote: Hi everyone,
I have just issued a pull request to the YTEP repository containing an initial draft of yt team guidelines. I encourage everyone to take a look at it and offer their feedback. In case you don't get the notification, the PR can be viewed here:
https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras...
Britton
On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith
wrote: > > Hi Sam, > > This is an excellent point. I think it's important not to > overburden a > single person by being forever responsible for a large chunk of the > code. I > also think it's good to give as many as are willing an opportunity > to > share > the role. Perhaps there is a team of people or subcommittee that > is > responsible for figuring out who their representative is. This can > be > ironed out. > > I think we've gotten enough positive response to start thinking > about a > YTEP that lays it all out. I will start something this week, ask > for > feedback, and we can all develop this together. > > In the mean time, if you would still like to chime in on this > discussion, > please do so. > Thanks, everyone. > > Britton > > > On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman > > wrote: >> >> Hi all, >> >> Britton -- I really like these ideas, and I like the member level >> being >> defined as write access. >> >> I'm a bit more concerned about the officers designation in terms >> of >> the >> logistics of matching people with sections of the code. I could >> see >> something working where on a 6-month basis, each of the main areas >> in >> yt are >> assigned a lead. That lead isn't necessarily the person who has >> written the >> most in the area, but rather a person who is willing to keep track >> of >> that >> area of the codebase for the next 6 months, so that when it comes >> to >> doing >> releases, they are the ones that know what has changed and where >> things are >> not working well. Maybe that's too much of a process, but I also >> think we >> should be wary of assigning potentially long-lasting labels to >> either >> people >> or code. Semi-regular meetings for this set of people would be >> great. >> >> Anyways, I'm definitely a +1 on a YTEP for all of this, and look >> forward >> to hearing more! >> >> Cheers, >> Sam >> >> >> On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller >> >> wrote: >>> >>> +1, absolutely. Right now, yt has a really high bus factor. I >>> think >>> this would help that a lot. >>> >>> >>> On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone >>> >>> wrote: >>>> >>>> +1 as well on all suggestions >>>> >>>> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki >>>> > wrote: >>>> > >>>> > I wanted to put my strong +1 out there even though I don't >>>> > respond >>>> > often to dev emails. This sounds like a great direction for >>>> > yt! >>>> > >>>> > -Kenza >>>> > >>>> > --- >>>> > Kenza Arraki >>>> > PhD candidate >>>> > New Mexico State University >>>> > Department of Astronomy >>>> > >>>> > >>>> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale >>>> > wrote: >>>> >> these all sound like good ideas to me. Some simply operating >>>> >> procedures, >>>> >> like "don't merge your own pull requests" might be good too. >>>> >> >>>> >> >>>> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith >>>> >> >>>> >> wrote: >>>> >>> >>>> >>> I'm very in favor of putting some official procedures into a >>>> >>> YTEP. >>>> >>> Having >>>> >>> a codified process may also help with conflict resolution as >>>> >>> well. >>>> >>> >>>> >>> Apache does something with their projects where developers >>>> >>> who >>>> >>> make >>>> >>> sustained contribution are made "members" after nomination >>>> >>> by >>>> >>> another member >>>> >>> and are given write access to the main repo. It's a small >>>> >>> thing, >>>> >>> but if we >>>> >>> perhaps have an official definition of "yt member" in a YTEP >>>> >>> with a >>>> >>> posted >>>> >>> list of members, it can be something people can point to as >>>> >>> a >>>> >>> way >>>> >>> of >>>> >>> demonstrating that they've done significant work on the >>>> >>> project. >>>> >>> >>>> >>> I think it might also be good to have officer-like positions >>>> >>> where >>>> >>> people >>>> >>> are representatives for various areas of the code, such as >>>> >>> data >>>> >>> structures, >>>> >>> visualization, analysis_modules, etc. and to have >>>> >>> semi-regular >>>> >>> meeting of >>>> >>> these people. This may be as much leadership as we need for >>>> >>> now, >>>> >>> just a >>>> >>> group that meets on a schedule to make sure everyone's on >>>> >>> the >>>> >>> same >>>> >>> page with >>>> >>> releases and major development efforts. >>>> >>> >>>> >>> What do people think of something like this? >>>> >>> >>>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk >>>> >>> >>>> >>> wrote: >>>> >>>> >>>> >>>> Hi Britton, >>>> >>>> >>>> >>>> Thanks for bringing this up -- it's a tough topic, but also >>>> >>>> I >>>> >>>> think >>>> >>>> really important. At the WSSSPE conference last year, a >>>> >>>> paper >>>> >>>> was >>>> >>>> submitted talking about the Apache model: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... >>>> >>>> >>>> >>>> which talks about a lot of related topics. Apache does >>>> >>>> some >>>> >>>> interesting things. They use the word "meritocracy" which >>>> >>>> I am >>>> >>>> rather >>>> >>>> -1 on using (see, for instance, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... >>>> >>>> ) but I do think there is something to be said for a large >>>> >>>> part >>>> >>>> of >>>> >>>> their methods of organization. >>>> >>>> >>>> >>>> Like you, I think we are overdue. I would like to point >>>> >>>> out >>>> >>>> that, >>>> >>>> for >>>> >>>> all intents and purposes, you are *already* the ombudsman >>>> >>>> for >>>> >>>> the >>>> >>>> yt >>>> >>>> community. I don't think you're proposing we have a >>>> >>>> committee >>>> >>>> that >>>> >>>> bosses everyone around, but rather one that enables a >>>> >>>> larger >>>> >>>> number of >>>> >>>> people to have a say, particularly because yt has become >>>> >>>> embedded >>>> >>>> in >>>> >>>> many of our scientific workflows and it touches a lot of >>>> >>>> research >>>> >>>> activities now. I like the idea of members. I like the >>>> >>>> idea >>>> >>>> of a >>>> >>>> project management committee, but it's not clear to me how >>>> >>>> that >>>> >>>> would >>>> >>>> work, or which decisions we have made recently that they >>>> >>>> would >>>> >>>> weigh >>>> >>>> in on. I also really like the idea of having "code >>>> >>>> liasons" to >>>> >>>> different data platforms and/or communities, and the idea >>>> >>>> of >>>> >>>> having >>>> >>>> people who are responsible for many different areas of the >>>> >>>> code >>>> >>>> and >>>> >>>> codifying that in some way is quite attractive to me. >>>> >>>> >>>> >>>> For what it's worth, a few weeks ago I gave a presentation >>>> >>>> on >>>> >>>> my >>>> >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). The >>>> >>>> thing >>>> >>>> is, >>>> >>>> while I gave this presentation, it's just *my* vision -- it >>>> >>>> is >>>> >>>> not >>>> >>>> necessarily anyone else's vision. And I think it's time we >>>> >>>> have >>>> >>>> some >>>> >>>> method of taking into account a diverse set of opinions for >>>> >>>> what >>>> >>>> we as >>>> >>>> a community can emphasize, how we resolve conflicts, and so >>>> >>>> on >>>> >>>> and >>>> >>>> so >>>> >>>> forth. >>>> >>>> >>>> >>>> Again, thanks for bringing this up. We need to have this >>>> >>>> conversation. >>>> >>>> >>>> >>>> -Matt >>>> >>>> >>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith >>>> >>>> >>>> >>>> wrote: >>>> >>>>> Greeting yt developers, >>>> >>>>> >>>> >>>>> First, I want to congratulate everyone here on the >>>> >>>>> successful >>>> >>>>> release >>>> >>>>> of yt-3.0. This was a massive effort on the part of so >>>> >>>>> many >>>> >>>>> and >>>> >>>>> a >>>> >>>>> true testament to the strength of this team. >>>> >>>>> >>>> >>>>> At the time of writing this, there are 78 members of the >>>> >>>>> yt-dev >>>> >>>>> mailing list. As someone who does most of their work in >>>> >>>>> very >>>> >>>>> small >>>> >>>>> collaborations, this amazes me and make me very proud. In >>>> >>>>> case >>>> >>>>> you're >>>> >>>>> wondering, the yt-users list has 268 members. >>>> >>>>> >>>> >>>>> As a project, yt has a significant amount of >>>> >>>>> infrastructure: >>>> >>>>> code >>>> >>>>> review with pull requests, issue tracking, automated >>>> >>>>> testing, >>>> >>>>> emails >>>> >>>>> lists, an IRC channel, enhancement proposals, workshops. >>>> >>>>> All >>>> >>>>> of >>>> >>>>> this >>>> >>>>> is evidence of our legitimacy as a Real Thing. However, >>>> >>>>> one >>>> >>>>> big >>>> >>>>> missing piece is a system of governance. I don't know >>>> >>>>> exactly >>>> >>>>> what >>>> >>>>> this means, but I have some ideas, which I will share >>>> >>>>> below. >>>> >>>>> What I >>>> >>>>> want to do right now is to start a discussion that will, >>>> >>>>> hopefully, >>>> >>>>> include as many people as possible on this list. >>>> >>>>> >>>> >>>>> For me, governance means (roughly) the following: >>>> >>>>> >>>> >>>>> - a set of procedures in writing for how various things >>>> >>>>> are to >>>> >>>>> be >>>> >>>>> done, such as acceptance of pull requests, releases, >>>> >>>>> designating >>>> >>>>> developers as core contributors, etc. >>>> >>>>> >>>> >>>>> - a governing body to make decisions and help guide the >>>> >>>>> project. >>>> >>>>> >>>> >>>>> This accomplishes a number of things, which as a project I >>>> >>>>> think >>>> >>>>> we >>>> >>>>> need, such as: >>>> >>>>> >>>> >>>>> - overall stability of the project. >>>> >>>>> >>>> >>>>> - providing a system for conflict resolution. >>>> >>>>> >>>> >>>>> - maintaining the spirit of yt as a team effort. >>>> >>>>> >>>> >>>>> - providing a way for active contributors to get credit >>>> >>>>> for >>>> >>>>> their >>>> >>>>> contribution in the form of official recognition. >>>> >>>>> >>>> >>>>> >>>> >>>>> So, these are my initial thoughts, but I really think this >>>> >>>>> deserves a >>>> >>>>> thorough discussion with as many people participating as >>>> >>>>> possible. >>>> >>>>> Please, think about what governance means to you, whether >>>> >>>>> we >>>> >>>>> need >>>> >>>>> it, >>>> >>>>> what it should be, and what we might get out of it, and >>>> >>>>> share >>>> >>>>> your >>>> >>>>> thoughts over the next few days. I look forward to this >>>> >>>>> discussion. >>>> >>>>> >>>> >>>>> Britton >>>> >>>>> >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> yt-dev mailing list >>>> >>>>> yt-dev@lists.spacepope.org >>>> >>>>> >>>> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>> >>>> _______________________________________________ >>>> >>>> yt-dev mailing list >>>> >>>> yt-dev@lists.spacepope.org >>>> >>>> >>>> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>> >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> yt-dev mailing list >>>> >>> yt-dev@lists.spacepope.org >>>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Michael Zingale >>>> >> Associate Professor >>>> >> >>>> >> Dept. of Physics & Astronomy • Stony Brook University • Stony >>>> >> Brook, >>>> >> NY >>>> >> 11794-3800 >>>> >> phone: 631-632-8225 >>>> >> e-mail: Michael.Zingale@stonybrook.edu >>>> >> web: http://www.astro.sunysb.edu/mzingale >>>> >> >>>> >> _______________________________________________ >>>> >> yt-dev mailing list >>>> >> yt-dev@lists.spacepope.org >>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>> > _______________________________________________ >>>> > yt-dev mailing list >>>> > yt-dev@lists.spacepope.org >>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>> _______________________________________________ >>>> yt-dev mailing list >>>> yt-dev@lists.spacepope.org >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >>> >>> >>> _______________________________________________ >>> yt-dev mailing list >>> yt-dev@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Sat, Aug 30, 2014 at 9:50 AM, Matthew Turk
I want to emphasize that the initial list of members Britton came up with (as he noted in the proposal) is only an *initial* list, and will hopefully very quickly expand to include less active "developers" who are nonetheless embedded in the community.
-Matt
And this is why I think we need a list of people who are regarded as "core" developers, to differentiate them from the what will likely be a very large list of "members". Right now from a professional standpoint, there is very little benefit from contributing to the code base, in that very few people recognize your contributions (ie a handful of other developers). Aside from a list of core developers that are highlighted on the webpage, or having a new yt paper come out, I don't see any other way in which this can be remedied. Perhaps others have ideas?
Brian
On Sat, Aug 30, 2014 at 9:30 AM, Britton Smith
wrote: HI Brian,
I couldn't agree more on having a documentation representative present
team meetings. In fact, I think this was even in my original draft, but I somehow lost track of it. Thanks for bringing it up. I will get that back in there. A community representative is also a good idea, but I'm less sure how that role would be filled. If anyone has any thoughts on that,
do share. If it can't be figured out before the YTEP is accepted, we can definitely amend it. Thanks, Brian!
Britton
On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk
wrote: Hi Brian,
On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea
wrote:
Hi folks,
Chiming in as somebody who is on the far periphery of yt development (having only contributed a couple of bug fixes/minor updates), I think that creation of a formal governance structure is a significant positive step. Given the distributed nature of the development team some level of coordination is critical, and I also think that having a set of carefully-considered standards about who gets a vote in terms of code direction, and how many of these votes are needed to enact substantial change (as opposed to the ad-hoc "preponderance of +1s from the mailing list" method) is an exceedingly good idea, as it will hopefully enhance the group's decision-making and make it more reflective.
I also want to comment on the monthly team meetings. In addition to posting meeting minutes, perhaps the meeting coordinator or secretary could organize an agenda for the meeting and post it to the yt-dev mailing list a couple of days ahead of time? That way, people who are not participating in
meeting, but who may have some input on the issues at hand, have an opportunity to email suggestions.
Finally, one other point: I can't help but notice that while the technical aspects of yt will be represented in these team meetings, there is no *explicit* representation of the yt user community or yt documentation. While in principle this isn't a problem -- Matt has made the point many times that the difference between user and developer isn't necessarily meaningful in our context -- I do think that having somebody involved whose explicit responsibility is to consider the questions "how will this impact the broader yt user community?" and "what's missing from the documentation that could be added or improved?" may be beneficial.
Yes, I agree. I actually have a few people I would submit as nominations for this role, but it seems to me it's certainly one that should be represented.
Anyway, small nit-picks aside, I think this is a great idea. Thanks
to
Britton for starting the ball rolling!
--Brian
On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk
wrote:
Hi Britton,
I think this is really, really important, and I'm really happy with the YTEP as it stands.
We've only gotten feedback from a few people. I think it's really important to get both positive and negative feedback from people on this -- even to the level of "geez, stop taking yourselves so seriously!" :) Do you think maybe an email to the yt-users mailing list would be productive? Or even directly writing to the people identified as "founding" members?
-Matt
On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith
wrote: > Hi everyone, > > I have just issued a pull request to the YTEP repository containing
> an > initial draft of yt team guidelines. I encourage everyone to take a > look at > it and offer their feedback. In case you don't get the > notification, > the PR > can be viewed here: > > > https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras... > > Britton > > > On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith >
> wrote: >> >> Hi Sam, >> >> This is an excellent point. I think it's important not to >> overburden a >> single person by being forever responsible for a large chunk of >> code. I >> also think it's good to give as many as are willing an opportunity >> to >> share >> the role. Perhaps there is a team of people or subcommittee that >> is >> responsible for figuring out who their representative is. This can >> be >> ironed out. >> >> I think we've gotten enough positive response to start thinking >> about a >> YTEP that lays it all out. I will start something this week, ask >> for >> feedback, and we can all develop this together. >> >> In the mean time, if you would still like to chime in on this >> discussion, >> please do so. >> Thanks, everyone. >> >> Britton >> >> >> On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman >>
>> wrote: >>> >>> Hi all, >>> >>> Britton -- I really like these ideas, and I like the member level >>> being >>> defined as write access. >>> >>> I'm a bit more concerned about the officers designation in terms >>> of >>> the >>> logistics of matching people with sections of the code. I could >>> see >>> something working where on a 6-month basis, each of the main areas >>> in >>> yt are >>> assigned a lead. That lead isn't necessarily the person who has >>> written the >>> most in the area, but rather a person who is willing to keep >>> of >>> that >>> area of the codebase for the next 6 months, so that when it comes >>> to >>> doing >>> releases, they are the ones that know what has changed and where >>> things are >>> not working well. Maybe that's too much of a process, but I also >>> think we >>> should be wary of assigning potentially long-lasting labels to >>> either >>> people >>> or code. Semi-regular meetings for this set of people would be >>> great. >>> >>> Anyways, I'm definitely a +1 on a YTEP for all of this, and look >>> forward >>> to hearing more! >>> >>> Cheers, >>> Sam >>> >>> >>> On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller >>>
>>> wrote: >>>> >>>> +1, absolutely. Right now, yt has a really high bus factor. I >>>> think >>>> this would help that a lot. >>>> >>>> >>>> On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone >>>> >>>> wrote: >>>>> >>>>> +1 as well on all suggestions >>>>> >>>>> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki >>>>> > wrote: >>>>> > >>>>> > I wanted to put my strong +1 out there even though I don't >>>>> > respond >>>>> > often to dev emails. This sounds like a great direction for >>>>> > yt! >>>>> > >>>>> > -Kenza >>>>> > >>>>> > --- >>>>> > Kenza Arraki >>>>> > PhD candidate >>>>> > New Mexico State University >>>>> > Department of Astronomy >>>>> > >>>>> > >>>>> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale >>>>> >
wrote: >>>>> >> these all sound like good ideas to me. Some simply operating >>>>> >> procedures, >>>>> >> like "don't merge your own pull requests" might be good too. >>>>> >> >>>>> >> >>>>> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith >>>>> >> >>>>> >> wrote: >>>>> >>> >>>>> >>> I'm very in favor of putting some official procedures into a >>>>> >>> YTEP. >>>>> >>> Having >>>>> >>> a codified process may also help with conflict resolution as >>>>> >>> well. >>>>> >>> >>>>> >>> Apache does something with their projects where developers >>>>> >>> who >>>>> >>> make >>>>> >>> sustained contribution are made "members" after nomination >>>>> >>> by >>>>> >>> another member >>>>> >>> and are given write access to the main repo. It's a small >>>>> >>> thing, >>>>> >>> but if we >>>>> >>> perhaps have an official definition of "yt member" in a YTEP >>>>> >>> with a >>>>> >>> posted >>>>> >>> list of members, it can be something people can point to as >>>>> >>> a >>>>> >>> way >>>>> >>> of >>>>> >>> demonstrating that they've done significant work on the >>>>> >>> project. >>>>> >>> >>>>> >>> I think it might also be good to have officer-like >>>>> >>> where >>>>> >>> people >>>>> >>> are representatives for various areas of the code, such as >>>>> >>> data >>>>> >>> structures, >>>>> >>> visualization, analysis_modules, etc. and to have >>>>> >>> semi-regular >>>>> >>> meeting of >>>>> >>> these people. This may be as much leadership as we need for >>>>> >>> now, >>>>> >>> just a >>>>> >>> group that meets on a schedule to make sure everyone's on >>>>> >>> the >>>>> >>> same >>>>> >>> page with >>>>> >>> releases and major development efforts. >>>>> >>> >>>>> >>> What do people think of something like this? >>>>> >>> >>>>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk >>>>> >>>
>>>>> >>> wrote: >>>>> >>>> >>>>> >>>> Hi Britton, >>>>> >>>> >>>>> >>>> Thanks for bringing this up -- it's a tough topic, but also >>>>> >>>> I >>>>> >>>> think >>>>> >>>> really important. At the WSSSPE conference last year, a >>>>> >>>> paper >>>>> >>>> was >>>>> >>>> submitted talking about the Apache model: >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... >>>>> >>>> >>>>> >>>> which talks about a lot of related topics. Apache does >>>>> >>>> some >>>>> >>>> interesting things. They use the word "meritocracy" which >>>>> >>>> I am >>>>> >>>> rather >>>>> >>>> -1 on using (see, for instance, >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... >>>>> >>>> ) but I do think there is something to be said for a large >>>>> >>>> part >>>>> >>>> of >>>>> >>>> their methods of organization. >>>>> >>>> >>>>> >>>> Like you, I think we are overdue. I would like to point >>>>> >>>> out >>>>> >>>> that, >>>>> >>>> for >>>>> >>>> all intents and purposes, you are *already* the ombudsman >>>>> >>>> for >>>>> >>>> the >>>>> >>>> yt >>>>> >>>> community. I don't think you're proposing we have a >>>>> >>>> committee >>>>> >>>> that >>>>> >>>> bosses everyone around, but rather one that enables a >>>>> >>>> larger >>>>> >>>> number of >>>>> >>>> people to have a say, particularly because yt has become >>>>> >>>> embedded >>>>> >>>> in >>>>> >>>> many of our scientific workflows and it touches a lot of >>>>> >>>> research >>>>> >>>> activities now. I like the idea of members. I like the >>>>> >>>> idea >>>>> >>>> of a >>>>> >>>> project management committee, but it's not clear to me how >>>>> >>>> that >>>>> >>>> would >>>>> >>>> work, or which decisions we have made recently that they >>>>> >>>> would >>>>> >>>> weigh >>>>> >>>> in on. I also really like the idea of having "code >>>>> >>>> liasons" to >>>>> >>>> different data platforms and/or communities, and the idea >>>>> >>>> of >>>>> >>>> having >>>>> >>>> people who are responsible for many different areas of >>>>> >>>> code >>>>> >>>> and >>>>> >>>> codifying that in some way is quite attractive to me. >>>>> >>>> >>>>> >>>> For what it's worth, a few weeks ago I gave a
>>>>> >>>> on >>>>> >>>> my >>>>> >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). The >>>>> >>>> thing >>>>> >>>> is, >>>>> >>>> while I gave this presentation, it's just *my* vision -- it >>>>> >>>> is >>>>> >>>> not >>>>> >>>> necessarily anyone else's vision. And I think it's time we >>>>> >>>> have >>>>> >>>> some >>>>> >>>> method of taking into account a diverse set of opinions for >>>>> >>>> what >>>>> >>>> we as >>>>> >>>> a community can emphasize, how we resolve conflicts, and so >>>>> >>>> on >>>>> >>>> and >>>>> >>>> so >>>>> >>>> forth. >>>>> >>>> >>>>> >>>> Again, thanks for bringing this up. We need to have this >>>>> >>>> conversation. >>>>> >>>> >>>>> >>>> -Matt >>>>> >>>> >>>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith >>>>> >>>>
>>>>> >>>> wrote: >>>>> >>>>> Greeting yt developers, >>>>> >>>>> >>>>> >>>>> First, I want to congratulate everyone here on the >>>>> >>>>> successful >>>>> >>>>> release >>>>> >>>>> of yt-3.0. This was a massive effort on the part of so >>>>> >>>>> many >>>>> >>>>> and >>>>> >>>>> a >>>>> >>>>> true testament to the strength of this team. >>>>> >>>>> >>>>> >>>>> At the time of writing this, there are 78 members of the >>>>> >>>>> yt-dev >>>>> >>>>> mailing list. As someone who does most of their work in >>>>> >>>>> very >>>>> >>>>> small >>>>> >>>>> collaborations, this amazes me and make me very proud. In >>>>> >>>>> case >>>>> >>>>> you're >>>>> >>>>> wondering, the yt-users list has 268 members. >>>>> >>>>> >>>>> >>>>> As a project, yt has a significant amount of >>>>> >>>>> infrastructure: >>>>> >>>>> code >>>>> >>>>> review with pull requests, issue tracking, automated >>>>> >>>>> testing, >>>>> >>>>> emails >>>>> >>>>> lists, an IRC channel, enhancement proposals, workshops. >>>>> >>>>> All >>>>> >>>>> of >>>>> >>>>> this >>>>> >>>>> is evidence of our legitimacy as a Real Thing. However, >>>>> >>>>> one >>>>> >>>>> big >>>>> >>>>> missing piece is a system of governance. I don't know >>>>> >>>>> exactly >>>>> >>>>> what >>>>> >>>>> this means, but I have some ideas, which I will share >>>>> >>>>> below. >>>>> >>>>> What I >>>>> >>>>> want to do right now is to start a discussion that will, >>>>> >>>>> hopefully, >>>>> >>>>> include as many people as possible on this list. >>>>> >>>>> >>>>> >>>>> For me, governance means (roughly) the following: >>>>> >>>>> >>>>> >>>>> - a set of procedures in writing for how various things >>>>> >>>>> are to >>>>> >>>>> be >>>>> >>>>> done, such as acceptance of pull requests, releases, >>>>> >>>>> designating >>>>> >>>>> developers as core contributors, etc. >>>>> >>>>> >>>>> >>>>> - a governing body to make decisions and help guide the >>>>> >>>>> project. >>>>> >>>>> >>>>> >>>>> This accomplishes a number of things, which as a >>>>> >>>>> think >>>>> >>>>> we >>>>> >>>>> need, such as: >>>>> >>>>> >>>>> >>>>> - overall stability of the project. >>>>> >>>>> >>>>> >>>>> - providing a system for conflict resolution. >>>>> >>>>> >>>>> >>>>> - maintaining the spirit of yt as a team effort. >>>>> >>>>> >>>>> >>>>> - providing a way for active contributors to get credit >>>>> >>>>> for >>>>> >>>>> their >>>>> >>>>> contribution in the form of official recognition. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> So, these are my initial thoughts, but I really think
at please the the track positions the presentation project I this
>>>>> >>>>> deserves a >>>>> >>>>> thorough discussion with as many people participating as >>>>> >>>>> possible. >>>>> >>>>> Please, think about what governance means to you, whether >>>>> >>>>> we >>>>> >>>>> need >>>>> >>>>> it, >>>>> >>>>> what it should be, and what we might get out of it, and >>>>> >>>>> share >>>>> >>>>> your >>>>> >>>>> thoughts over the next few days. I look forward to this >>>>> >>>>> discussion. >>>>> >>>>> >>>>> >>>>> Britton >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> yt-dev mailing list >>>>> >>>>> yt-dev@lists.spacepope.org >>>>> >>>>> >>>>> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>>> >>>> _______________________________________________ >>>>> >>>> yt-dev mailing list >>>>> >>>> yt-dev@lists.spacepope.org >>>>> >>>> >>>>> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> yt-dev mailing list >>>>> >>> yt-dev@lists.spacepope.org >>>>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>>> >> >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> Michael Zingale >>>>> >> Associate Professor >>>>> >> >>>>> >> Dept. of Physics & Astronomy • Stony Brook University • Stony >>>>> >> Brook, >>>>> >> NY >>>>> >> 11794-3800 >>>>> >> phone: 631-632-8225 >>>>> >> e-mail: Michael.Zingale@stonybrook.edu >>>>> >> web: http://www.astro.sunysb.edu/mzingale >>>>> >> >>>>> >> _______________________________________________ >>>>> >> yt-dev mailing list >>>>> >> yt-dev@lists.spacepope.org >>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>>> > _______________________________________________ >>>>> > yt-dev mailing list >>>>> > yt-dev@lists.spacepope.org >>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>>> _______________________________________________ >>>>> yt-dev mailing list >>>>> yt-dev@lists.spacepope.org >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>> >>>> >>>> >>>> _______________________________________________ >>>> yt-dev mailing list >>>> yt-dev@lists.spacepope.org >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>>> >>> >>> >>> _______________________________________________ >>> yt-dev mailing list >>> yt-dev@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
I agree with Cameron that ultimately some way of ensuring recognition for
the core developers (where len(core) < len(members)) is a good idea. Many
(most?) of the big contributors to yt are in junior-level positions, and
getting the recognition for their efforts will be important to getting into
them more permanent positions. Unfortunately, for computational
astrophysics, contributing to a software project doesn't carry as much
weight as a scientific study in the eyes of the committees that do the
hiring. I don't know what the right answer is, but I think Cameron's point
needs to be discussed further, so that those people who are
concerned/curious understand the incentive structure.
On Sat, Aug 30, 2014 at 4:18 PM, Cameron Hummels
On Sat, Aug 30, 2014 at 9:50 AM, Matthew Turk
wrote: I want to emphasize that the initial list of members Britton came up with (as he noted in the proposal) is only an *initial* list, and will hopefully very quickly expand to include less active "developers" who are nonetheless embedded in the community.
-Matt
And this is why I think we need a list of people who are regarded as "core" developers, to differentiate them from the what will likely be a very large list of "members". Right now from a professional standpoint, there is very little benefit from contributing to the code base, in that very few people recognize your contributions (ie a handful of other developers). Aside from a list of core developers that are highlighted on the webpage, or having a new yt paper come out, I don't see any other way in which this can be remedied. Perhaps others have ideas?
Brian
On Sat, Aug 30, 2014 at 9:30 AM, Britton Smith
wrote: HI Brian,
I couldn't agree more on having a documentation representative present
team meetings. In fact, I think this was even in my original draft, but I somehow lost track of it. Thanks for bringing it up. I will get that back in there. A community representative is also a good idea, but I'm less sure how that role would be filled. If anyone has any thoughts on that,
do share. If it can't be figured out before the YTEP is accepted, we can definitely amend it. Thanks, Brian!
Britton
On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk
wrote: Hi Brian,
On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea
wrote:
Hi folks,
Chiming in as somebody who is on the far periphery of yt development (having only contributed a couple of bug fixes/minor updates), I think that creation of a formal governance structure is a significant positive step. Given the distributed nature of the development team some level of coordination is critical, and I also think that having a set of carefully-considered standards about who gets a vote in terms of code direction, and how many of these votes are needed to enact substantial change (as opposed to
ad-hoc "preponderance of +1s from the mailing list" method) is an exceedingly good idea, as it will hopefully enhance the group's decision-making and make it more reflective.
I also want to comment on the monthly team meetings. In addition to posting meeting minutes, perhaps the meeting coordinator or secretary could organize an agenda for the meeting and post it to the yt-dev mailing list a couple of days ahead of time? That way, people who are not participating in
meeting, but who may have some input on the issues at hand, have an opportunity to email suggestions.
Finally, one other point: I can't help but notice that while the technical aspects of yt will be represented in these team meetings, there is no *explicit* representation of the yt user community or yt documentation. While in principle this isn't a problem -- Matt has made the point many times that the difference between user and developer isn't necessarily meaningful in our context -- I do think that having somebody involved whose explicit responsibility is to consider the questions "how will this impact the broader yt user community?" and "what's missing from the documentation that could be added or improved?" may be beneficial.
Yes, I agree. I actually have a few people I would submit as nominations for this role, but it seems to me it's certainly one that should be represented.
Anyway, small nit-picks aside, I think this is a great idea.
Thanks to
Britton for starting the ball rolling!
--Brian
On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk < matthewturk@gmail.com> wrote: > > Hi Britton, > > I think this is really, really important, and I'm really happy with > the YTEP as it stands. > > We've only gotten feedback from a few people. I think it's really > important to get both positive and negative feedback from people on > this -- even to the level of "geez, stop taking yourselves so > seriously!" :) Do you think maybe an email to the yt-users mailing > list would be productive? Or even directly writing to the people > identified as "founding" members? > > -Matt > > On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith >
> wrote: > > Hi everyone, > > > > I have just issued a pull request to the YTEP repository containing > > an > > initial draft of yt team guidelines. I encourage everyone to take a > > look at > > it and offer their feedback. In case you don't get the > > notification, > > the PR > > can be viewed here: > > > > > > https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras... > > > > Britton > > > > > > On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith > > > > wrote: > >> > >> Hi Sam, > >> > >> This is an excellent point. I think it's important not to > >> overburden a > >> single person by being forever responsible for a large chunk of > >> code. I > >> also think it's good to give as many as are willing an opportunity > >> to > >> share > >> the role. Perhaps there is a team of people or subcommittee
> >> is > >> responsible for figuring out who their representative is. This can > >> be > >> ironed out. > >> > >> I think we've gotten enough positive response to start thinking > >> about a > >> YTEP that lays it all out. I will start something this week, ask > >> for > >> feedback, and we can all develop this together. > >> > >> In the mean time, if you would still like to chime in on this > >> discussion, > >> please do so. > >> Thanks, everyone. > >> > >> Britton > >> > >> > >> On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman > >>
> >> wrote: > >>> > >>> Hi all, > >>> > >>> Britton -- I really like these ideas, and I like the member level > >>> being > >>> defined as write access. > >>> > >>> I'm a bit more concerned about the officers designation in terms > >>> of > >>> the > >>> logistics of matching people with sections of the code. I could > >>> see > >>> something working where on a 6-month basis, each of the main areas > >>> in > >>> yt are > >>> assigned a lead. That lead isn't necessarily the person who has > >>> written the > >>> most in the area, but rather a person who is willing to keep > >>> of > >>> that > >>> area of the codebase for the next 6 months, so that when it comes > >>> to > >>> doing > >>> releases, they are the ones that know what has changed and where > >>> things are > >>> not working well. Maybe that's too much of a process, but I also > >>> think we > >>> should be wary of assigning potentially long-lasting labels to > >>> either > >>> people > >>> or code. Semi-regular meetings for this set of people would be > >>> great. > >>> > >>> Anyways, I'm definitely a +1 on a YTEP for all of this, and look > >>> forward > >>> to hearing more! > >>> > >>> Cheers, > >>> Sam > >>> > >>> > >>> On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller > >>>
> >>> wrote: > >>>> > >>>> +1, absolutely. Right now, yt has a really high bus factor. I > >>>> think > >>>> this would help that a lot. > >>>> > >>>> > >>>> On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone > >>>> > >>>> wrote: > >>>>> > >>>>> +1 as well on all suggestions > >>>>> > >>>>> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki < karraki@nmsu.edu> > >>>>> > wrote: > >>>>> > > >>>>> > I wanted to put my strong +1 out there even though I don't > >>>>> > respond > >>>>> > often to dev emails. This sounds like a great direction for > >>>>> > yt! > >>>>> > > >>>>> > -Kenza > >>>>> > > >>>>> > --- > >>>>> > Kenza Arraki > >>>>> > PhD candidate > >>>>> > New Mexico State University > >>>>> > Department of Astronomy > >>>>> > > >>>>> > > >>>>> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale > >>>>> > wrote: > >>>>> >> these all sound like good ideas to me. Some simply operating > >>>>> >> procedures, > >>>>> >> like "don't merge your own pull requests" might be good too. > >>>>> >> > >>>>> >> > >>>>> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith > >>>>> >> > >>>>> >> wrote: > >>>>> >>> > >>>>> >>> I'm very in favor of putting some official procedures into a > >>>>> >>> YTEP. > >>>>> >>> Having > >>>>> >>> a codified process may also help with conflict resolution as > >>>>> >>> well. > >>>>> >>> > >>>>> >>> Apache does something with their projects where developers > >>>>> >>> who > >>>>> >>> make > >>>>> >>> sustained contribution are made "members" after nomination > >>>>> >>> by > >>>>> >>> another member > >>>>> >>> and are given write access to the main repo. It's a small > >>>>> >>> thing, > >>>>> >>> but if we > >>>>> >>> perhaps have an official definition of "yt member" in a YTEP > >>>>> >>> with a > >>>>> >>> posted > >>>>> >>> list of members, it can be something people can point to as > >>>>> >>> a > >>>>> >>> way > >>>>> >>> of > >>>>> >>> demonstrating that they've done significant work on the > >>>>> >>> project. > >>>>> >>> > >>>>> >>> I think it might also be good to have officer-like > >>>>> >>> where > >>>>> >>> people > >>>>> >>> are representatives for various areas of the code, such as > >>>>> >>> data > >>>>> >>> structures, > >>>>> >>> visualization, analysis_modules, etc. and to have > >>>>> >>> semi-regular > >>>>> >>> meeting of > >>>>> >>> these people. This may be as much leadership as we need for > >>>>> >>> now, > >>>>> >>> just a > >>>>> >>> group that meets on a schedule to make sure everyone's on > >>>>> >>> the > >>>>> >>> same > >>>>> >>> page with > >>>>> >>> releases and major development efforts. > >>>>> >>> > >>>>> >>> What do people think of something like this? > >>>>> >>> > >>>>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk > >>>>> >>>
> >>>>> >>> wrote: > >>>>> >>>> > >>>>> >>>> Hi Britton, > >>>>> >>>> > >>>>> >>>> Thanks for bringing this up -- it's a tough topic, but also > >>>>> >>>> I > >>>>> >>>> think > >>>>> >>>> really important. At the WSSSPE conference last year, a > >>>>> >>>> paper > >>>>> >>>> was > >>>>> >>>> submitted talking about the Apache model: > >>>>> >>>> > >>>>> >>>> > >>>>> >>>> > >>>>> >>>> > >>>>> >>>> > >>>>> >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... > >>>>> >>>> > >>>>> >>>> which talks about a lot of related topics. Apache does > >>>>> >>>> some > >>>>> >>>> interesting things. They use the word "meritocracy" which > >>>>> >>>> I am > >>>>> >>>> rather > >>>>> >>>> -1 on using (see, for instance, > >>>>> >>>> > >>>>> >>>> > >>>>> >>>> > >>>>> >>>> > >>>>> >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... > >>>>> >>>> ) but I do think there is something to be said for a large > >>>>> >>>> part > >>>>> >>>> of > >>>>> >>>> their methods of organization. > >>>>> >>>> > >>>>> >>>> Like you, I think we are overdue. I would like to point > >>>>> >>>> out > >>>>> >>>> that, > >>>>> >>>> for > >>>>> >>>> all intents and purposes, you are *already* the ombudsman > >>>>> >>>> for > >>>>> >>>> the > >>>>> >>>> yt > >>>>> >>>> community. I don't think you're proposing we have a > >>>>> >>>> committee > >>>>> >>>> that > >>>>> >>>> bosses everyone around, but rather one that enables a > >>>>> >>>> larger > >>>>> >>>> number of > >>>>> >>>> people to have a say, particularly because yt has become > >>>>> >>>> embedded > >>>>> >>>> in > >>>>> >>>> many of our scientific workflows and it touches a lot of > >>>>> >>>> research > >>>>> >>>> activities now. I like the idea of members. I like the > >>>>> >>>> idea > >>>>> >>>> of a > >>>>> >>>> project management committee, but it's not clear to me how > >>>>> >>>> that > >>>>> >>>> would > >>>>> >>>> work, or which decisions we have made recently that they > >>>>> >>>> would > >>>>> >>>> weigh > >>>>> >>>> in on. I also really like the idea of having "code > >>>>> >>>> liasons" to > >>>>> >>>> different data platforms and/or communities, and the idea > >>>>> >>>> of > >>>>> >>>> having > >>>>> >>>> people who are responsible for many different areas of > >>>>> >>>> code > >>>>> >>>> and > >>>>> >>>> codifying that in some way is quite attractive to me. > >>>>> >>>> > >>>>> >>>> For what it's worth, a few weeks ago I gave a
> >>>>> >>>> on > >>>>> >>>> my > >>>>> >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). The > >>>>> >>>> thing > >>>>> >>>> is, > >>>>> >>>> while I gave this presentation, it's just *my* vision -- it > >>>>> >>>> is > >>>>> >>>> not > >>>>> >>>> necessarily anyone else's vision. And I think it's time we > >>>>> >>>> have > >>>>> >>>> some > >>>>> >>>> method of taking into account a diverse set of opinions for > >>>>> >>>> what > >>>>> >>>> we as > >>>>> >>>> a community can emphasize, how we resolve conflicts, and so > >>>>> >>>> on > >>>>> >>>> and > >>>>> >>>> so > >>>>> >>>> forth. > >>>>> >>>> > >>>>> >>>> Again, thanks for bringing this up. We need to have
> >>>>> >>>> conversation. > >>>>> >>>> > >>>>> >>>> -Matt > >>>>> >>>> > >>>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith > >>>>> >>>>
> >>>>> >>>> wrote: > >>>>> >>>>> Greeting yt developers, > >>>>> >>>>> > >>>>> >>>>> First, I want to congratulate everyone here on the > >>>>> >>>>> successful > >>>>> >>>>> release > >>>>> >>>>> of yt-3.0. This was a massive effort on the part of so > >>>>> >>>>> many > >>>>> >>>>> and > >>>>> >>>>> a > >>>>> >>>>> true testament to the strength of this team. > >>>>> >>>>> > >>>>> >>>>> At the time of writing this, there are 78 members of > >>>>> >>>>> yt-dev > >>>>> >>>>> mailing list. As someone who does most of their work in > >>>>> >>>>> very > >>>>> >>>>> small > >>>>> >>>>> collaborations, this amazes me and make me very
> >>>>> >>>>> case > >>>>> >>>>> you're > >>>>> >>>>> wondering, the yt-users list has 268 members. > >>>>> >>>>> > >>>>> >>>>> As a project, yt has a significant amount of > >>>>> >>>>> infrastructure: > >>>>> >>>>> code > >>>>> >>>>> review with pull requests, issue tracking, automated > >>>>> >>>>> testing, > >>>>> >>>>> emails > >>>>> >>>>> lists, an IRC channel, enhancement proposals, workshops. > >>>>> >>>>> All > >>>>> >>>>> of > >>>>> >>>>> this > >>>>> >>>>> is evidence of our legitimacy as a Real Thing. However, > >>>>> >>>>> one > >>>>> >>>>> big > >>>>> >>>>> missing piece is a system of governance. I don't know > >>>>> >>>>> exactly > >>>>> >>>>> what > >>>>> >>>>> this means, but I have some ideas, which I will share > >>>>> >>>>> below. > >>>>> >>>>> What I > >>>>> >>>>> want to do right now is to start a discussion that will, > >>>>> >>>>> hopefully, > >>>>> >>>>> include as many people as possible on this list. > >>>>> >>>>> > >>>>> >>>>> For me, governance means (roughly) the following: > >>>>> >>>>> > >>>>> >>>>> - a set of procedures in writing for how various things > >>>>> >>>>> are to > >>>>> >>>>> be > >>>>> >>>>> done, such as acceptance of pull requests, releases, > >>>>> >>>>> designating > >>>>> >>>>> developers as core contributors, etc. > >>>>> >>>>> > >>>>> >>>>> - a governing body to make decisions and help guide the > >>>>> >>>>> project. > >>>>> >>>>> > >>>>> >>>>> This accomplishes a number of things, which as a
> >>>>> >>>>> think > >>>>> >>>>> we > >>>>> >>>>> need, such as: > >>>>> >>>>> > >>>>> >>>>> - overall stability of the project. > >>>>> >>>>> > >>>>> >>>>> - providing a system for conflict resolution. > >>>>> >>>>> > >>>>> >>>>> - maintaining the spirit of yt as a team effort. > >>>>> >>>>> > >>>>> >>>>> - providing a way for active contributors to get credit > >>>>> >>>>> for > >>>>> >>>>> their > >>>>> >>>>> contribution in the form of official recognition. > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> So, these are my initial thoughts, but I really think
> >>>>> >>>>> deserves a > >>>>> >>>>> thorough discussion with as many people participating as > >>>>> >>>>> possible. > >>>>> >>>>> Please, think about what governance means to you, whether > >>>>> >>>>> we > >>>>> >>>>> need > >>>>> >>>>> it, > >>>>> >>>>> what it should be, and what we might get out of it, and > >>>>> >>>>> share > >>>>> >>>>> your > >>>>> >>>>> thoughts over the next few days. I look forward to
at please the the the that track positions the presentation this the proud. In project I this this
> >>>>> >>>>> discussion. > >>>>> >>>>> > >>>>> >>>>> Britton > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> _______________________________________________ > >>>>> >>>>> yt-dev mailing list > >>>>> >>>>> yt-dev@lists.spacepope.org > >>>>> >>>>> > >>>>> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>>>> >>>> _______________________________________________ > >>>>> >>>> yt-dev mailing list > >>>>> >>>> yt-dev@lists.spacepope.org > >>>>> >>>> > >>>>> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> >>> _______________________________________________ > >>>>> >>> yt-dev mailing list > >>>>> >>> yt-dev@lists.spacepope.org > >>>>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> -- > >>>>> >> Michael Zingale > >>>>> >> Associate Professor > >>>>> >> > >>>>> >> Dept. of Physics & Astronomy • Stony Brook University • Stony > >>>>> >> Brook, > >>>>> >> NY > >>>>> >> 11794-3800 > >>>>> >> phone: 631-632-8225 > >>>>> >> e-mail: Michael.Zingale@stonybrook.edu > >>>>> >> web: http://www.astro.sunysb.edu/mzingale > >>>>> >> > >>>>> >> _______________________________________________ > >>>>> >> yt-dev mailing list > >>>>> >> yt-dev@lists.spacepope.org > >>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>>>> > _______________________________________________ > >>>>> > yt-dev mailing list > >>>>> > yt-dev@lists.spacepope.org > >>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>>>> _______________________________________________ > >>>>> yt-dev mailing list > >>>>> yt-dev@lists.spacepope.org > >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> yt-dev mailing list > >>>> yt-dev@lists.spacepope.org > >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>>> > >>> > >>> > >>> _______________________________________________ > >>> yt-dev mailing list > >>> yt-dev@lists.spacepope.org > >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> > >> > > > > > > _______________________________________________ > > yt-dev mailing list > > yt-dev@lists.spacepope.org > > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
Cameron, I think this is a very valid issue that you raise. I have a couple concerns about creating a tier of "core" contributors on top of the member tier. I also have another idea at the end. First, it is not clear to me the process by which we would establish the bar for a core contributor. I was comfortable with doing this rather ad-hoc for member status because it was designed to be inclusive and to establish a way that we could make decisions as a team. However, I don't think we can do that for this since it is creating a more exclusive group. If something like this is going to be created, then I think it needs to be done through the body of members that we will soon have. Otherwise, I don't know how it can be done fairly. Second, I'm not sure that designating core contributors will be any more effective at properly crediting people for their work. At the end of the day, it will be another label that says in rather general terms that someone is very important to a project. I have been referring to myself as a core developer on job applications for a few years now and I don't think it's gotten me anything. Maybe that would change if there were an official definition of that term. I would like to put forth another idea that could perhaps accomplish the same goal. Following the YTEP on governance, we are going to create a webpage on yt-project.org with an official definition of yt member status and a list of all members. I think it would be good if we allow those members to write bios for themselves that are linked to off of the member page. Those bios could contain anything you would want someone to know about your involvement in the project: how long you've been around, what features you've worked on, a link to your page on openhub.net, any other activities or things you've been a part of, whatever you want. That way you can not only be seen as a important person, but can get the specific credit that you deserve. Other people could even point out things that one might have missed. Maybe this will help the project seem less like a monolith and more like a lot of individual valuable pieces. In conclusion, I am not totally opposed to core status, as long as it can be created in a fair and open way, but I would also really like to hear what people think about the bios. Britton On Sun, Aug 31, 2014 at 12:08 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I agree with Cameron that ultimately some way of ensuring recognition for the core developers (where len(core) < len(members)) is a good idea. Many (most?) of the big contributors to yt are in junior-level positions, and getting the recognition for their efforts will be important to getting into them more permanent positions. Unfortunately, for computational astrophysics, contributing to a software project doesn't carry as much weight as a scientific study in the eyes of the committees that do the hiring. I don't know what the right answer is, but I think Cameron's point needs to be discussed further, so that those people who are concerned/curious understand the incentive structure.
On Sat, Aug 30, 2014 at 4:18 PM, Cameron Hummels
wrote: On Sat, Aug 30, 2014 at 9:50 AM, Matthew Turk
wrote: I want to emphasize that the initial list of members Britton came up with (as he noted in the proposal) is only an *initial* list, and will hopefully very quickly expand to include less active "developers" who are nonetheless embedded in the community.
-Matt
And this is why I think we need a list of people who are regarded as "core" developers, to differentiate them from the what will likely be a very large list of "members". Right now from a professional standpoint, there is very little benefit from contributing to the code base, in that very few people recognize your contributions (ie a handful of other developers). Aside from a list of core developers that are highlighted on the webpage, or having a new yt paper come out, I don't see any other way in which this can be remedied. Perhaps others have ideas?
Brian
On Sat, Aug 30, 2014 at 9:30 AM, Britton Smith
wrote:
HI Brian,
I couldn't agree more on having a documentation representative
team meetings. In fact, I think this was even in my original draft, but I somehow lost track of it. Thanks for bringing it up. I will get
in there. A community representative is also a good idea, but I'm less sure how that role would be filled. If anyone has any thoughts on that,
do share. If it can't be figured out before the YTEP is accepted, we can definitely amend it. Thanks, Brian!
Britton
On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk
wrote:
Hi Brian,
On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea
wrote:
> Hi folks, > > Chiming in as somebody who is on the far periphery of yt development > (having > only contributed a couple of bug fixes/minor updates), I think that > creation > of a formal governance structure is a significant positive step. Given > the > distributed nature of the development team some level of coordination > is > critical, and I also think that having a set of carefully-considered > standards about who gets a vote in terms of code direction, and how > many of > these votes are needed to enact substantial change (as opposed to
> ad-hoc > "preponderance of +1s from the mailing list" method) is an exceedingly > good > idea, as it will hopefully enhance the group's decision-making and make > it > more reflective. > > I also want to comment on the monthly team meetings. In addition to > posting > meeting minutes, perhaps the meeting coordinator or secretary could > organize > an agenda for the meeting and post it to the yt-dev mailing list a > couple of > days ahead of time? That way, people who are not participating in
> meeting, but who may have some input on the issues at hand, have an > opportunity to email suggestions. > > Finally, one other point: I can't help but notice that while the > technical > aspects of yt will be represented in these team meetings, there is no > *explicit* representation of the yt user community or yt documentation. > While in principle this isn't a problem -- Matt has made the point many > times that the difference between user and developer isn't necessarily > meaningful in our context -- I do think that having somebody involved > whose > explicit responsibility is to consider the questions "how will this > impact > the broader yt user community?" and "what's missing from the > documentation > that could be added or improved?" may be beneficial.
Yes, I agree. I actually have a few people I would submit as nominations for this role, but it seems to me it's certainly one that should be represented.
> > Anyway, small nit-picks aside, I think this is a great idea. Thanks to > Britton for starting the ball rolling! > > --Brian > > > > > On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk < matthewturk@gmail.com> > wrote: >> >> Hi Britton, >> >> I think this is really, really important, and I'm really happy with >> the YTEP as it stands. >> >> We've only gotten feedback from a few people. I think it's really >> important to get both positive and negative feedback from people on >> this -- even to the level of "geez, stop taking yourselves so >> seriously!" :) Do you think maybe an email to the yt-users mailing >> list would be productive? Or even directly writing to the people >> identified as "founding" members? >> >> -Matt >> >> On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith >>
>> wrote: >> > Hi everyone, >> > >> > I have just issued a pull request to the YTEP repository containing >> > an >> > initial draft of yt team guidelines. I encourage everyone to take a >> > look at >> > it and offer their feedback. In case you don't get the >> > notification, >> > the PR >> > can be viewed here: >> > >> > >> > https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras... >> > >> > Britton >> > >> > >> > On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith >> > >> > wrote: >> >> >> >> Hi Sam, >> >> >> >> This is an excellent point. I think it's important not to >> >> overburden a >> >> single person by being forever responsible for a large chunk of the >> >> code. I >> >> also think it's good to give as many as are willing an opportunity >> >> to >> >> share >> >> the role. Perhaps there is a team of people or subcommittee >> >> is >> >> responsible for figuring out who their representative is. This can >> >> be >> >> ironed out. >> >> >> >> I think we've gotten enough positive response to start thinking >> >> about a >> >> YTEP that lays it all out. I will start something this week, ask >> >> for >> >> feedback, and we can all develop this together. >> >> >> >> In the mean time, if you would still like to chime in on this >> >> discussion, >> >> please do so. >> >> Thanks, everyone. >> >> >> >> Britton >> >> >> >> >> >> On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman >> >>
>> >> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> Britton -- I really like these ideas, and I like the member level >> >>> being >> >>> defined as write access. >> >>> >> >>> I'm a bit more concerned about the officers designation in terms >> >>> of >> >>> the >> >>> logistics of matching people with sections of the code. I could >> >>> see >> >>> something working where on a 6-month basis, each of the main areas >> >>> in >> >>> yt are >> >>> assigned a lead. That lead isn't necessarily the person who has >> >>> written the >> >>> most in the area, but rather a person who is willing to keep >> >>> of >> >>> that >> >>> area of the codebase for the next 6 months, so that when it comes >> >>> to >> >>> doing >> >>> releases, they are the ones that know what has changed and where >> >>> things are >> >>> not working well. Maybe that's too much of a process, but I also >> >>> think we >> >>> should be wary of assigning potentially long-lasting labels to >> >>> either >> >>> people >> >>> or code. Semi-regular meetings for this set of people would be >> >>> great. >> >>> >> >>> Anyways, I'm definitely a +1 on a YTEP for all of this, and look >> >>> forward >> >>> to hearing more! >> >>> >> >>> Cheers, >> >>> Sam >> >>> >> >>> >> >>> On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller >> >>>
>> >>> wrote: >> >>>> >> >>>> +1, absolutely. Right now, yt has a really high bus factor. I >> >>>> think >> >>>> this would help that a lot. >> >>>> >> >>>> >> >>>> On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone >> >>>> >> >>>> wrote: >> >>>>> >> >>>>> +1 as well on all suggestions >> >>>>> >> >>>>> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki < karraki@nmsu.edu> >> >>>>> > wrote: >> >>>>> > >> >>>>> > I wanted to put my strong +1 out there even though I don't >> >>>>> > respond >> >>>>> > often to dev emails. This sounds like a great direction for >> >>>>> > yt! >> >>>>> > >> >>>>> > -Kenza >> >>>>> > >> >>>>> > --- >> >>>>> > Kenza Arraki >> >>>>> > PhD candidate >> >>>>> > New Mexico State University >> >>>>> > Department of Astronomy >> >>>>> > >> >>>>> > >> >>>>> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale >> >>>>> > wrote: >> >>>>> >> these all sound like good ideas to me. Some simply operating >> >>>>> >> procedures, >> >>>>> >> like "don't merge your own pull requests" might be good too. >> >>>>> >> >> >>>>> >> >> >>>>> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith >> >>>>> >> >> >>>>> >> wrote: >> >>>>> >>> >> >>>>> >>> I'm very in favor of putting some official procedures into a >> >>>>> >>> YTEP. >> >>>>> >>> Having >> >>>>> >>> a codified process may also help with conflict resolution as >> >>>>> >>> well. >> >>>>> >>> >> >>>>> >>> Apache does something with their projects where developers >> >>>>> >>> who >> >>>>> >>> make >> >>>>> >>> sustained contribution are made "members" after nomination >> >>>>> >>> by >> >>>>> >>> another member >> >>>>> >>> and are given write access to the main repo. It's a small >> >>>>> >>> thing, >> >>>>> >>> but if we >> >>>>> >>> perhaps have an official definition of "yt member" in a YTEP >> >>>>> >>> with a >> >>>>> >>> posted >> >>>>> >>> list of members, it can be something people can point to as >> >>>>> >>> a >> >>>>> >>> way >> >>>>> >>> of >> >>>>> >>> demonstrating that they've done significant work on the >> >>>>> >>> project. >> >>>>> >>> >> >>>>> >>> I think it might also be good to have officer-like >> >>>>> >>> where >> >>>>> >>> people >> >>>>> >>> are representatives for various areas of the code, such as >> >>>>> >>> data >> >>>>> >>> structures, >> >>>>> >>> visualization, analysis_modules, etc. and to have >> >>>>> >>> semi-regular >> >>>>> >>> meeting of >> >>>>> >>> these people. This may be as much leadership as we need for >> >>>>> >>> now, >> >>>>> >>> just a >> >>>>> >>> group that meets on a schedule to make sure everyone's on >> >>>>> >>> the >> >>>>> >>> same >> >>>>> >>> page with >> >>>>> >>> releases and major development efforts. >> >>>>> >>> >> >>>>> >>> What do people think of something like this? >> >>>>> >>> >> >>>>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk >> >>>>> >>>
>> >>>>> >>> wrote: >> >>>>> >>>> >> >>>>> >>>> Hi Britton, >> >>>>> >>>> >> >>>>> >>>> Thanks for bringing this up -- it's a tough topic, but also >> >>>>> >>>> I >> >>>>> >>>> think >> >>>>> >>>> really important. At the WSSSPE conference last year, a >> >>>>> >>>> paper >> >>>>> >>>> was >> >>>>> >>>> submitted talking about the Apache model: >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... >> >>>>> >>>> >> >>>>> >>>> which talks about a lot of related topics. Apache does >> >>>>> >>>> some >> >>>>> >>>> interesting things. They use the word "meritocracy" which >> >>>>> >>>> I am >> >>>>> >>>> rather >> >>>>> >>>> -1 on using (see, for instance, >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... >> >>>>> >>>> ) but I do think there is something to be said for a large >> >>>>> >>>> part >> >>>>> >>>> of >> >>>>> >>>> their methods of organization. >> >>>>> >>>> >> >>>>> >>>> Like you, I think we are overdue. I would like to >> >>>>> >>>> out >> >>>>> >>>> that, >> >>>>> >>>> for >> >>>>> >>>> all intents and purposes, you are *already* the ombudsman >> >>>>> >>>> for >> >>>>> >>>> the >> >>>>> >>>> yt >> >>>>> >>>> community. I don't think you're proposing we have a >> >>>>> >>>> committee >> >>>>> >>>> that >> >>>>> >>>> bosses everyone around, but rather one that enables a >> >>>>> >>>> larger >> >>>>> >>>> number of >> >>>>> >>>> people to have a say, particularly because yt has become >> >>>>> >>>> embedded >> >>>>> >>>> in >> >>>>> >>>> many of our scientific workflows and it touches a lot of >> >>>>> >>>> research >> >>>>> >>>> activities now. I like the idea of members. I like
>> >>>>> >>>> idea >> >>>>> >>>> of a >> >>>>> >>>> project management committee, but it's not clear to me how >> >>>>> >>>> that >> >>>>> >>>> would >> >>>>> >>>> work, or which decisions we have made recently that
>> >>>>> >>>> would >> >>>>> >>>> weigh >> >>>>> >>>> in on. I also really like the idea of having "code >> >>>>> >>>> liasons" to >> >>>>> >>>> different data platforms and/or communities, and the idea >> >>>>> >>>> of >> >>>>> >>>> having >> >>>>> >>>> people who are responsible for many different areas of
>> >>>>> >>>> code >> >>>>> >>>> and >> >>>>> >>>> codifying that in some way is quite attractive to me. >> >>>>> >>>> >> >>>>> >>>> For what it's worth, a few weeks ago I gave a
>> >>>>> >>>> on >> >>>>> >>>> my >> >>>>> >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). The >> >>>>> >>>> thing >> >>>>> >>>> is, >> >>>>> >>>> while I gave this presentation, it's just *my* vision -- it >> >>>>> >>>> is >> >>>>> >>>> not >> >>>>> >>>> necessarily anyone else's vision. And I think it's time we >> >>>>> >>>> have >> >>>>> >>>> some >> >>>>> >>>> method of taking into account a diverse set of opinions for >> >>>>> >>>> what >> >>>>> >>>> we as >> >>>>> >>>> a community can emphasize, how we resolve conflicts, and so >> >>>>> >>>> on >> >>>>> >>>> and >> >>>>> >>>> so >> >>>>> >>>> forth. >> >>>>> >>>> >> >>>>> >>>> Again, thanks for bringing this up. We need to have
>> >>>>> >>>> conversation. >> >>>>> >>>> >> >>>>> >>>> -Matt >> >>>>> >>>> >> >>>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith >> >>>>> >>>>
>> >>>>> >>>> wrote: >> >>>>> >>>>> Greeting yt developers, >> >>>>> >>>>> >> >>>>> >>>>> First, I want to congratulate everyone here on the >> >>>>> >>>>> successful >> >>>>> >>>>> release >> >>>>> >>>>> of yt-3.0. This was a massive effort on the part of so >> >>>>> >>>>> many >> >>>>> >>>>> and >> >>>>> >>>>> a >> >>>>> >>>>> true testament to the strength of this team. >> >>>>> >>>>> >> >>>>> >>>>> At the time of writing this, there are 78 members of >> >>>>> >>>>> yt-dev >> >>>>> >>>>> mailing list. As someone who does most of their work in >> >>>>> >>>>> very >> >>>>> >>>>> small >> >>>>> >>>>> collaborations, this amazes me and make me very
>> >>>>> >>>>> case >> >>>>> >>>>> you're >> >>>>> >>>>> wondering, the yt-users list has 268 members. >> >>>>> >>>>> >> >>>>> >>>>> As a project, yt has a significant amount of >> >>>>> >>>>> infrastructure: >> >>>>> >>>>> code >> >>>>> >>>>> review with pull requests, issue tracking, automated >> >>>>> >>>>> testing, >> >>>>> >>>>> emails >> >>>>> >>>>> lists, an IRC channel, enhancement proposals, workshops. >> >>>>> >>>>> All >> >>>>> >>>>> of >> >>>>> >>>>> this >> >>>>> >>>>> is evidence of our legitimacy as a Real Thing. However, >> >>>>> >>>>> one >> >>>>> >>>>> big >> >>>>> >>>>> missing piece is a system of governance. I don't know >> >>>>> >>>>> exactly >> >>>>> >>>>> what >> >>>>> >>>>> this means, but I have some ideas, which I will share >> >>>>> >>>>> below. >> >>>>> >>>>> What I >> >>>>> >>>>> want to do right now is to start a discussion that will, >> >>>>> >>>>> hopefully, >> >>>>> >>>>> include as many people as possible on this list. >> >>>>> >>>>> >> >>>>> >>>>> For me, governance means (roughly) the following: >> >>>>> >>>>> >> >>>>> >>>>> - a set of procedures in writing for how various
>> >>>>> >>>>> are to >> >>>>> >>>>> be >> >>>>> >>>>> done, such as acceptance of pull requests, releases, >> >>>>> >>>>> designating >> >>>>> >>>>> developers as core contributors, etc. >> >>>>> >>>>> >> >>>>> >>>>> - a governing body to make decisions and help guide
>> >>>>> >>>>> project. >> >>>>> >>>>> >> >>>>> >>>>> This accomplishes a number of things, which as a
>> >>>>> >>>>> think >> >>>>> >>>>> we >> >>>>> >>>>> need, such as: >> >>>>> >>>>> >> >>>>> >>>>> - overall stability of the project. >> >>>>> >>>>> >> >>>>> >>>>> - providing a system for conflict resolution. >> >>>>> >>>>> >> >>>>> >>>>> - maintaining the spirit of yt as a team effort. >> >>>>> >>>>> >> >>>>> >>>>> - providing a way for active contributors to get credit >> >>>>> >>>>> for >> >>>>> >>>>> their >> >>>>> >>>>> contribution in the form of official recognition. >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> So, these are my initial thoughts, but I really think
>> >>>>> >>>>> deserves a >> >>>>> >>>>> thorough discussion with as many people participating as >> >>>>> >>>>> possible. >> >>>>> >>>>> Please, think about what governance means to you, whether >> >>>>> >>>>> we >> >>>>> >>>>> need >> >>>>> >>>>> it, >> >>>>> >>>>> what it should be, and what we might get out of it, and >> >>>>> >>>>> share >> >>>>> >>>>> your >> >>>>> >>>>> thoughts over the next few days. I look forward to
present at that back please the the that track positions point the they the presentation this the proud. In things the project I this this
>> >>>>> >>>>> discussion. >> >>>>> >>>>> >> >>>>> >>>>> Britton >> >>>>> >>>>> >> >>>>> >>>>> >> >>>>> >>>>> _______________________________________________ >> >>>>> >>>>> yt-dev mailing list >> >>>>> >>>>> yt-dev@lists.spacepope.org >> >>>>> >>>>> >> >>>>> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>>>> >>>> _______________________________________________ >> >>>>> >>>> yt-dev mailing list >> >>>>> >>>> yt-dev@lists.spacepope.org >> >>>>> >>>> >> >>>>> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>>>> >>> >> >>>>> >>> >> >>>>> >>> >> >>>>> >>> _______________________________________________ >> >>>>> >>> yt-dev mailing list >> >>>>> >>> yt-dev@lists.spacepope.org >> >>>>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> -- >> >>>>> >> Michael Zingale >> >>>>> >> Associate Professor >> >>>>> >> >> >>>>> >> Dept. of Physics & Astronomy • Stony Brook University • Stony >> >>>>> >> Brook, >> >>>>> >> NY >> >>>>> >> 11794-3800 >> >>>>> >> phone: 631-632-8225 >> >>>>> >> e-mail: Michael.Zingale@stonybrook.edu >> >>>>> >> web: http://www.astro.sunysb.edu/mzingale >> >>>>> >> >> >>>>> >> _______________________________________________ >> >>>>> >> yt-dev mailing list >> >>>>> >> yt-dev@lists.spacepope.org >> >>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>>>> > _______________________________________________ >> >>>>> > yt-dev mailing list >> >>>>> > yt-dev@lists.spacepope.org >> >>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>>>> _______________________________________________ >> >>>>> yt-dev mailing list >> >>>>> yt-dev@lists.spacepope.org >> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> yt-dev mailing list >> >>>> yt-dev@lists.spacepope.org >> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> yt-dev mailing list >> >>> yt-dev@lists.spacepope.org >> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> >> >> >> > >> > >> > _______________________________________________ >> > yt-dev mailing list >> > yt-dev@lists.spacepope.org >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I'd like to second Britton's suggestion, and elaborate on them a bit. I've
been on both sides of this particular issue - applying for jobs, and also
looking at peoples' CVs for postdocs and faculty positions - and it's tough
to get "credit" for software in the same way that you get credit for
peer-reviewed journal articles, particularly if you're developing a
community code like yt (or Enzo). But, it's easier when somebody has made
well-defined and significant contributions to a particular project, has
documented that in various ways (i.e., in a bio, Open HUB, your CV, etc.),
and in particular when that person's letter-writers have talked about it in
their letters and put it in context (i.e., "Dr. X was the primary developer
of yt's widely-used Foo Generator module, wrote the underlying parallel
infrastructure that allows it to strongly scale to 300 quintillion cores
for arbitrarily small data volumes, and has been active in improving this
code and supporting its use in the yt user community for the past four
years. The Foo Generator has been a key part of the analysis done in at
least 14 journal articles since its first release, the majority of which
would not have been written were it not for Dr. X's contribution to yt.
Furthermore, Dr. X has played key roles in the development of X, Y, and Z
modules for Enzo, which demonstrates Dr. X's understanding of a wide
variety of numerical algorithms, particularly for large-scale parallel
computing."
So, my elaboration on Britton's suggestion is really to take advantage of
the bios to lay out what peoples' major contributions have been to the yt
project, which is useful for lots of purposes - including giving
information to potential employers, letter-writers, and people who are
looking to update individual pieces of yt but don't know who they should
talk to. It's not perfect, but it could help a bit.
Also, to the original point: I think that making tiers of contributors
(i.e., "core" vs. "the teeming masses") is a recipe for resentment in the
long term, as it becomes exclusive rather than inclusive. I can imagine a
variety of conversations taking place, if only in somebody's head: "Core
Developer X hasn't contributed in two years, and I've been really active
for the past eighteen months - why are they still listed as a core
developer and I'm not one?" or, "If the requirement is X changesets, I can
game the system by making lots of very small changes and thus become a core
developer." or, "If only the core developers get a say in the direction of
the code, why should I even bother contributing?" And so on. Of course,
it's reasonable to call yourself a core developer, and to ask
letter-writers to mention that you are one, but establishing a formal set
of requirements seems like it's asking for trouble.
--Brian
On Sun, Aug 31, 2014 at 9:07 AM, Britton Smith
Cameron,
I think this is a very valid issue that you raise. I have a couple concerns about creating a tier of "core" contributors on top of the member tier. I also have another idea at the end.
First, it is not clear to me the process by which we would establish the bar for a core contributor. I was comfortable with doing this rather ad-hoc for member status because it was designed to be inclusive and to establish a way that we could make decisions as a team. However, I don't think we can do that for this since it is creating a more exclusive group. If something like this is going to be created, then I think it needs to be done through the body of members that we will soon have. Otherwise, I don't know how it can be done fairly.
Second, I'm not sure that designating core contributors will be any more effective at properly crediting people for their work. At the end of the day, it will be another label that says in rather general terms that someone is very important to a project. I have been referring to myself as a core developer on job applications for a few years now and I don't think it's gotten me anything. Maybe that would change if there were an official definition of that term.
I would like to put forth another idea that could perhaps accomplish the same goal. Following the YTEP on governance, we are going to create a webpage on yt-project.org with an official definition of yt member status and a list of all members. I think it would be good if we allow those members to write bios for themselves that are linked to off of the member page. Those bios could contain anything you would want someone to know about your involvement in the project: how long you've been around, what features you've worked on, a link to your page on openhub.net, any other activities or things you've been a part of, whatever you want. That way you can not only be seen as a important person, but can get the specific credit that you deserve. Other people could even point out things that one might have missed. Maybe this will help the project seem less like a monolith and more like a lot of individual valuable pieces.
In conclusion, I am not totally opposed to core status, as long as it can be created in a fair and open way, but I would also really like to hear what people think about the bios.
Britton
On Sun, Aug 31, 2014 at 12:08 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I agree with Cameron that ultimately some way of ensuring recognition for the core developers (where len(core) < len(members)) is a good idea. Many (most?) of the big contributors to yt are in junior-level positions, and getting the recognition for their efforts will be important to getting into them more permanent positions. Unfortunately, for computational astrophysics, contributing to a software project doesn't carry as much weight as a scientific study in the eyes of the committees that do the hiring. I don't know what the right answer is, but I think Cameron's point needs to be discussed further, so that those people who are concerned/curious understand the incentive structure.
On Sat, Aug 30, 2014 at 4:18 PM, Cameron Hummels
wrote: On Sat, Aug 30, 2014 at 9:50 AM, Matthew Turk
wrote: I want to emphasize that the initial list of members Britton came up with (as he noted in the proposal) is only an *initial* list, and will hopefully very quickly expand to include less active "developers" who are nonetheless embedded in the community.
-Matt
And this is why I think we need a list of people who are regarded as "core" developers, to differentiate them from the what will likely be a very large list of "members". Right now from a professional standpoint, there is very little benefit from contributing to the code base, in that very few people recognize your contributions (ie a handful of other developers). Aside from a list of core developers that are highlighted on the webpage, or having a new yt paper come out, I don't see any other way in which this can be remedied. Perhaps others have ideas?
Brian
On Sat, Aug 30, 2014 at 9:30 AM, Britton Smith <
wrote:
HI Brian,
I couldn't agree more on having a documentation representative
team meetings. In fact, I think this was even in my original draft, but I somehow lost track of it. Thanks for bringing it up. I will get
in there. A community representative is also a good idea, but I'm less sure how that role would be filled. If anyone has any thoughts on that,
do share. If it can't be figured out before the YTEP is accepted, we can definitely amend it. Thanks, Brian!
Britton
On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk < matthewturk@gmail.com> wrote: > > Hi Brian, > > On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea
wrote: > > Hi folks, > > > > Chiming in as somebody who is on the far periphery of yt development > > (having > > only contributed a couple of bug fixes/minor updates), I think > > creation > > of a formal governance structure is a significant positive step. Given > > the > > distributed nature of the development team some level of coordination > > is > > critical, and I also think that having a set of carefully-considered > > standards about who gets a vote in terms of code direction, and how > > many of > > these votes are needed to enact substantial change (as opposed to
> > ad-hoc > > "preponderance of +1s from the mailing list" method) is an exceedingly > > good > > idea, as it will hopefully enhance the group's decision-making and make > > it > > more reflective. > > > > I also want to comment on the monthly team meetings. In addition to > > posting > > meeting minutes, perhaps the meeting coordinator or secretary could > > organize > > an agenda for the meeting and post it to the yt-dev mailing list a > > couple of > > days ahead of time? That way, people who are not participating in the > > meeting, but who may have some input on the issues at hand, have an > > opportunity to email suggestions. > > > > Finally, one other point: I can't help but notice that while the > > technical > > aspects of yt will be represented in these team meetings, there is no > > *explicit* representation of the yt user community or yt documentation. > > While in principle this isn't a problem -- Matt has made the
> > times that the difference between user and developer isn't necessarily > > meaningful in our context -- I do think that having somebody involved > > whose > > explicit responsibility is to consider the questions "how will
> > impact > > the broader yt user community?" and "what's missing from the > > documentation > > that could be added or improved?" may be beneficial. > > Yes, I agree. I actually have a few people I would submit as > nominations for this role, but it seems to me it's certainly one
> should be represented. > > > > > Anyway, small nit-picks aside, I think this is a great idea. Thanks to > > Britton for starting the ball rolling! > > > > --Brian > > > > > > > > > > On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk < matthewturk@gmail.com> > > wrote: > >> > >> Hi Britton, > >> > >> I think this is really, really important, and I'm really happy with > >> the YTEP as it stands. > >> > >> We've only gotten feedback from a few people. I think it's really > >> important to get both positive and negative feedback from people on > >> this -- even to the level of "geez, stop taking yourselves so > >> seriously!" :) Do you think maybe an email to the yt-users mailing > >> list would be productive? Or even directly writing to the people > >> identified as "founding" members? > >> > >> -Matt > >> > >> On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith > >>
> >> wrote: > >> > Hi everyone, > >> > > >> > I have just issued a pull request to the YTEP repository containing > >> > an > >> > initial draft of yt team guidelines. I encourage everyone to take a > >> > look at > >> > it and offer their feedback. In case you don't get the > >> > notification, > >> > the PR > >> > can be viewed here: > >> > > >> > > >> > https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras... > >> > > >> > Britton > >> > > >> > > >> > On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith > >> > > >> > wrote: > >> >> > >> >> Hi Sam, > >> >> > >> >> This is an excellent point. I think it's important not to > >> >> overburden a > >> >> single person by being forever responsible for a large chunk of the > >> >> code. I > >> >> also think it's good to give as many as are willing an opportunity > >> >> to > >> >> share > >> >> the role. Perhaps there is a team of people or subcommittee > >> >> is > >> >> responsible for figuring out who their representative is. This can > >> >> be > >> >> ironed out. > >> >> > >> >> I think we've gotten enough positive response to start
> >> >> about a > >> >> YTEP that lays it all out. I will start something this week, ask > >> >> for > >> >> feedback, and we can all develop this together. > >> >> > >> >> In the mean time, if you would still like to chime in on this > >> >> discussion, > >> >> please do so. > >> >> Thanks, everyone. > >> >> > >> >> Britton > >> >> > >> >> > >> >> On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman > >> >>
> >> >> wrote: > >> >>> > >> >>> Hi all, > >> >>> > >> >>> Britton -- I really like these ideas, and I like the member level > >> >>> being > >> >>> defined as write access. > >> >>> > >> >>> I'm a bit more concerned about the officers designation in terms > >> >>> of > >> >>> the > >> >>> logistics of matching people with sections of the code. I could > >> >>> see > >> >>> something working where on a 6-month basis, each of the main areas > >> >>> in > >> >>> yt are > >> >>> assigned a lead. That lead isn't necessarily the person who has > >> >>> written the > >> >>> most in the area, but rather a person who is willing to keep > >> >>> of > >> >>> that > >> >>> area of the codebase for the next 6 months, so that when it comes > >> >>> to > >> >>> doing > >> >>> releases, they are the ones that know what has changed and where > >> >>> things are > >> >>> not working well. Maybe that's too much of a process, but I also > >> >>> think we > >> >>> should be wary of assigning potentially long-lasting labels to > >> >>> either > >> >>> people > >> >>> or code. Semi-regular meetings for this set of people would be > >> >>> great. > >> >>> > >> >>> Anyways, I'm definitely a +1 on a YTEP for all of this, and look > >> >>> forward > >> >>> to hearing more! > >> >>> > >> >>> Cheers, > >> >>> Sam > >> >>> > >> >>> > >> >>> On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller > >> >>>
> >> >>> wrote: > >> >>>> > >> >>>> +1, absolutely. Right now, yt has a really high bus factor. I > >> >>>> think > >> >>>> this would help that a lot. > >> >>>> > >> >>>> > >> >>>> On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone > >> >>>> > >> >>>> wrote: > >> >>>>> > >> >>>>> +1 as well on all suggestions > >> >>>>> > >> >>>>> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki < karraki@nmsu.edu> > >> >>>>> > wrote: > >> >>>>> > > >> >>>>> > I wanted to put my strong +1 out there even though I don't > >> >>>>> > respond > >> >>>>> > often to dev emails. This sounds like a great direction for > >> >>>>> > yt! > >> >>>>> > > >> >>>>> > -Kenza > >> >>>>> > > >> >>>>> > --- > >> >>>>> > Kenza Arraki > >> >>>>> > PhD candidate > >> >>>>> > New Mexico State University > >> >>>>> > Department of Astronomy > >> >>>>> > > >> >>>>> > > >> >>>>> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale > >> >>>>> > wrote: > >> >>>>> >> these all sound like good ideas to me. Some simply operating > >> >>>>> >> procedures, > >> >>>>> >> like "don't merge your own pull requests" might be good too. > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith > >> >>>>> >> > >> >>>>> >> wrote: > >> >>>>> >>> > >> >>>>> >>> I'm very in favor of putting some official procedures into a > >> >>>>> >>> YTEP. > >> >>>>> >>> Having > >> >>>>> >>> a codified process may also help with conflict resolution as > >> >>>>> >>> well. > >> >>>>> >>> > >> >>>>> >>> Apache does something with their projects where developers > >> >>>>> >>> who > >> >>>>> >>> make > >> >>>>> >>> sustained contribution are made "members" after nomination > >> >>>>> >>> by > >> >>>>> >>> another member > >> >>>>> >>> and are given write access to the main repo. It's a small > >> >>>>> >>> thing, > >> >>>>> >>> but if we > >> >>>>> >>> perhaps have an official definition of "yt member" in a YTEP > >> >>>>> >>> with a > >> >>>>> >>> posted > >> >>>>> >>> list of members, it can be something people can point to as > >> >>>>> >>> a > >> >>>>> >>> way > >> >>>>> >>> of > >> >>>>> >>> demonstrating that they've done significant work on the > >> >>>>> >>> project. > >> >>>>> >>> > >> >>>>> >>> I think it might also be good to have officer-like > >> >>>>> >>> where > >> >>>>> >>> people > >> >>>>> >>> are representatives for various areas of the code, such as > >> >>>>> >>> data > >> >>>>> >>> structures, > >> >>>>> >>> visualization, analysis_modules, etc. and to have > >> >>>>> >>> semi-regular > >> >>>>> >>> meeting of > >> >>>>> >>> these people. This may be as much leadership as we need for > >> >>>>> >>> now, > >> >>>>> >>> just a > >> >>>>> >>> group that meets on a schedule to make sure everyone's on > >> >>>>> >>> the > >> >>>>> >>> same > >> >>>>> >>> page with > >> >>>>> >>> releases and major development efforts. > >> >>>>> >>> > >> >>>>> >>> What do people think of something like this? > >> >>>>> >>> > >> >>>>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk > >> >>>>> >>>
> >> >>>>> >>> wrote: > >> >>>>> >>>> > >> >>>>> >>>> Hi Britton, > >> >>>>> >>>> > >> >>>>> >>>> Thanks for bringing this up -- it's a tough topic, but also > >> >>>>> >>>> I > >> >>>>> >>>> think > >> >>>>> >>>> really important. At the WSSSPE conference last year, a > >> >>>>> >>>> paper > >> >>>>> >>>> was > >> >>>>> >>>> submitted talking about the Apache model: > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... > >> >>>>> >>>> > >> >>>>> >>>> which talks about a lot of related topics. Apache does > >> >>>>> >>>> some > >> >>>>> >>>> interesting things. They use the word "meritocracy" which > >> >>>>> >>>> I am > >> >>>>> >>>> rather > >> >>>>> >>>> -1 on using (see, for instance, > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... > >> >>>>> >>>> ) but I do think there is something to be said for a large > >> >>>>> >>>> part > >> >>>>> >>>> of > >> >>>>> >>>> their methods of organization. > >> >>>>> >>>> > >> >>>>> >>>> Like you, I think we are overdue. I would like to > >> >>>>> >>>> out > >> >>>>> >>>> that, > >> >>>>> >>>> for > >> >>>>> >>>> all intents and purposes, you are *already* the ombudsman > >> >>>>> >>>> for > >> >>>>> >>>> the > >> >>>>> >>>> yt > >> >>>>> >>>> community. I don't think you're proposing we have a > >> >>>>> >>>> committee > >> >>>>> >>>> that > >> >>>>> >>>> bosses everyone around, but rather one that enables a > >> >>>>> >>>> larger > >> >>>>> >>>> number of > >> >>>>> >>>> people to have a say, particularly because yt has become > >> >>>>> >>>> embedded > >> >>>>> >>>> in > >> >>>>> >>>> many of our scientific workflows and it touches a lot of > >> >>>>> >>>> research > >> >>>>> >>>> activities now. I like the idea of members. I like
> >> >>>>> >>>> idea > >> >>>>> >>>> of a > >> >>>>> >>>> project management committee, but it's not clear to me how > >> >>>>> >>>> that > >> >>>>> >>>> would > >> >>>>> >>>> work, or which decisions we have made recently that
> >> >>>>> >>>> would > >> >>>>> >>>> weigh > >> >>>>> >>>> in on. I also really like the idea of having "code > >> >>>>> >>>> liasons" to > >> >>>>> >>>> different data platforms and/or communities, and the idea > >> >>>>> >>>> of > >> >>>>> >>>> having > >> >>>>> >>>> people who are responsible for many different areas of the > >> >>>>> >>>> code > >> >>>>> >>>> and > >> >>>>> >>>> codifying that in some way is quite attractive to me. > >> >>>>> >>>> > >> >>>>> >>>> For what it's worth, a few weeks ago I gave a
> >> >>>>> >>>> on > >> >>>>> >>>> my > >> >>>>> >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). The > >> >>>>> >>>> thing > >> >>>>> >>>> is, > >> >>>>> >>>> while I gave this presentation, it's just *my* vision -- it > >> >>>>> >>>> is > >> >>>>> >>>> not > >> >>>>> >>>> necessarily anyone else's vision. And I think it's time we > >> >>>>> >>>> have > >> >>>>> >>>> some > >> >>>>> >>>> method of taking into account a diverse set of opinions for > >> >>>>> >>>> what > >> >>>>> >>>> we as > >> >>>>> >>>> a community can emphasize, how we resolve conflicts, and so > >> >>>>> >>>> on > >> >>>>> >>>> and > >> >>>>> >>>> so > >> >>>>> >>>> forth. > >> >>>>> >>>> > >> >>>>> >>>> Again, thanks for bringing this up. We need to have
> >> >>>>> >>>> conversation. > >> >>>>> >>>> > >> >>>>> >>>> -Matt > >> >>>>> >>>> > >> >>>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith > >> >>>>> >>>>
> >> >>>>> >>>> wrote: > >> >>>>> >>>>> Greeting yt developers, > >> >>>>> >>>>> > >> >>>>> >>>>> First, I want to congratulate everyone here on the > >> >>>>> >>>>> successful > >> >>>>> >>>>> release > >> >>>>> >>>>> of yt-3.0. This was a massive effort on the part of so > >> >>>>> >>>>> many > >> >>>>> >>>>> and > >> >>>>> >>>>> a > >> >>>>> >>>>> true testament to the strength of this team. > >> >>>>> >>>>> > >> >>>>> >>>>> At the time of writing this, there are 78 members of > >> >>>>> >>>>> yt-dev > >> >>>>> >>>>> mailing list. As someone who does most of their work in > >> >>>>> >>>>> very > >> >>>>> >>>>> small > >> >>>>> >>>>> collaborations, this amazes me and make me very
> >> >>>>> >>>>> case > >> >>>>> >>>>> you're > >> >>>>> >>>>> wondering, the yt-users list has 268 members. > >> >>>>> >>>>> > >> >>>>> >>>>> As a project, yt has a significant amount of > >> >>>>> >>>>> infrastructure: > >> >>>>> >>>>> code > >> >>>>> >>>>> review with pull requests, issue tracking, automated > >> >>>>> >>>>> testing, > >> >>>>> >>>>> emails > >> >>>>> >>>>> lists, an IRC channel, enhancement proposals, workshops. > >> >>>>> >>>>> All > >> >>>>> >>>>> of > >> >>>>> >>>>> this > >> >>>>> >>>>> is evidence of our legitimacy as a Real Thing. However, > >> >>>>> >>>>> one > >> >>>>> >>>>> big > >> >>>>> >>>>> missing piece is a system of governance. I don't know > >> >>>>> >>>>> exactly > >> >>>>> >>>>> what > >> >>>>> >>>>> this means, but I have some ideas, which I will share > >> >>>>> >>>>> below. > >> >>>>> >>>>> What I > >> >>>>> >>>>> want to do right now is to start a discussion that will, > >> >>>>> >>>>> hopefully, > >> >>>>> >>>>> include as many people as possible on this list. > >> >>>>> >>>>> > >> >>>>> >>>>> For me, governance means (roughly) the following: > >> >>>>> >>>>> > >> >>>>> >>>>> - a set of procedures in writing for how various
> >> >>>>> >>>>> are to > >> >>>>> >>>>> be > >> >>>>> >>>>> done, such as acceptance of pull requests, releases, > >> >>>>> >>>>> designating > >> >>>>> >>>>> developers as core contributors, etc. > >> >>>>> >>>>> > >> >>>>> >>>>> - a governing body to make decisions and help guide
> >> >>>>> >>>>> project. > >> >>>>> >>>>> > >> >>>>> >>>>> This accomplishes a number of things, which as a
> >> >>>>> >>>>> think > >> >>>>> >>>>> we > >> >>>>> >>>>> need, such as: > >> >>>>> >>>>> > >> >>>>> >>>>> - overall stability of the project. > >> >>>>> >>>>> > >> >>>>> >>>>> - providing a system for conflict resolution. > >> >>>>> >>>>> > >> >>>>> >>>>> - maintaining the spirit of yt as a team effort. > >> >>>>> >>>>> > >> >>>>> >>>>> - providing a way for active contributors to get credit > >> >>>>> >>>>> for > >> >>>>> >>>>> their > >> >>>>> >>>>> contribution in the form of official recognition. > >> >>>>> >>>>> > >> >>>>> >>>>> > >> >>>>> >>>>> So, these are my initial thoughts, but I really
> >> >>>>> >>>>> deserves a > >> >>>>> >>>>> thorough discussion with as many people
> >> >>>>> >>>>> possible. > >> >>>>> >>>>> Please, think about what governance means to you, whether > >> >>>>> >>>>> we > >> >>>>> >>>>> need > >> >>>>> >>>>> it, > >> >>>>> >>>>> what it should be, and what we might get out of it, and > >> >>>>> >>>>> share > >> >>>>> >>>>> your > >> >>>>> >>>>> thoughts over the next few days. I look forward to
brittonsmith@gmail.com> present at that back please that the point many this that that thinking track positions point the they presentation this the proud. In things the project I think this participating as this
> >> >>>>> >>>>> discussion. > >> >>>>> >>>>> > >> >>>>> >>>>> Britton > >> >>>>> >>>>> > >> >>>>> >>>>> > >> >>>>> >>>>> _______________________________________________ > >> >>>>> >>>>> yt-dev mailing list > >> >>>>> >>>>> yt-dev@lists.spacepope.org > >> >>>>> >>>>> > >> >>>>> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>>> >>>> _______________________________________________ > >> >>>>> >>>> yt-dev mailing list > >> >>>>> >>>> yt-dev@lists.spacepope.org > >> >>>>> >>>> > >> >>>>> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>>> >>> > >> >>>>> >>> > >> >>>>> >>> > >> >>>>> >>> _______________________________________________ > >> >>>>> >>> yt-dev mailing list > >> >>>>> >>> yt-dev@lists.spacepope.org > >> >>>>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> -- > >> >>>>> >> Michael Zingale > >> >>>>> >> Associate Professor > >> >>>>> >> > >> >>>>> >> Dept. of Physics & Astronomy • Stony Brook University • Stony > >> >>>>> >> Brook, > >> >>>>> >> NY > >> >>>>> >> 11794-3800 > >> >>>>> >> phone: 631-632-8225 > >> >>>>> >> e-mail: Michael.Zingale@stonybrook.edu > >> >>>>> >> web: http://www.astro.sunysb.edu/mzingale > >> >>>>> >> > >> >>>>> >> _______________________________________________ > >> >>>>> >> yt-dev mailing list > >> >>>>> >> yt-dev@lists.spacepope.org > >> >>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>>> > _______________________________________________ > >> >>>>> > yt-dev mailing list > >> >>>>> > yt-dev@lists.spacepope.org > >> >>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>>> _______________________________________________ > >> >>>>> yt-dev mailing list > >> >>>>> yt-dev@lists.spacepope.org > >> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>> > >> >>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> yt-dev mailing list > >> >>>> yt-dev@lists.spacepope.org > >> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>> > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> yt-dev mailing list > >> >>> yt-dev@lists.spacepope.org > >> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>> > >> >> > >> > > >> > > >> > _______________________________________________ > >> > yt-dev mailing list > >> > yt-dev@lists.spacepope.org > >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> > > >> _______________________________________________ > >> yt-dev mailing list > >> yt-dev@lists.spacepope.org > >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > > > > > _______________________________________________ > > yt-dev mailing list > > yt-dev@lists.spacepope.org > > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I hate to be the person that responds to my own post, but I also just
remembered that there are some new (and old) journals that might be worth
looking at, if one wants to publish the details of individual yt modules:
Astronomy and Computing:
http://www.journals.elsevier.com/astronomy-and-computing/
Computational Astrophysics and Cosmology:
http://www.comp-astrophys-cosmol.com/
Computer Physics Communications:
http://www.journals.elsevier.com/computer-physics-communications/
Journal of Computational Physics:
http://www.journals.elsevier.com/journal-of-computational-physics/
Publications of the Astronomical Society of the Pacific:
http://www.press.uchicago.edu/ucp/journals/journal/pasp.html
If there's a truly innovative/useful piece of code, it might be worth
writing it up in one of those. Some are really new (A&C, CompAC), but
maybe worth trying out. These two new journals in particular seem to be
designed for this sort of thing - in their charters they both mention data
analysis and visualization software, and A&C states that this journal
"accepts regular scientific articles and review articles, but will also
consider manuscripts on new software and data releases of astronomical
surveys, and "reports on practice" which describe the outcomes (positive
and negative) of the practical application of informatics techniques within
astronomy research and operations... Providing a sustainable link to data
or source code is strongly encouraged." This seems to include a lot of
what we do. And, of course, for new versions of yt, one could always
imagine a follow-up paper in ApJS - the original yt ApJS method paper has
135 citations, as of today!
--Brian
On Mon, Sep 1, 2014 at 1:32 PM, Brian O'Shea
I'd like to second Britton's suggestion, and elaborate on them a bit. I've been on both sides of this particular issue - applying for jobs, and also looking at peoples' CVs for postdocs and faculty positions - and it's tough to get "credit" for software in the same way that you get credit for peer-reviewed journal articles, particularly if you're developing a community code like yt (or Enzo). But, it's easier when somebody has made well-defined and significant contributions to a particular project, has documented that in various ways (i.e., in a bio, Open HUB, your CV, etc.), and in particular when that person's letter-writers have talked about it in their letters and put it in context (i.e., "Dr. X was the primary developer of yt's widely-used Foo Generator module, wrote the underlying parallel infrastructure that allows it to strongly scale to 300 quintillion cores for arbitrarily small data volumes, and has been active in improving this code and supporting its use in the yt user community for the past four years. The Foo Generator has been a key part of the analysis done in at least 14 journal articles since its first release, the majority of which would not have been written were it not for Dr. X's contribution to yt. Furthermore, Dr. X has played key roles in the development of X, Y, and Z modules for Enzo, which demonstrates Dr. X's understanding of a wide variety of numerical algorithms, particularly for large-scale parallel computing."
So, my elaboration on Britton's suggestion is really to take advantage of the bios to lay out what peoples' major contributions have been to the yt project, which is useful for lots of purposes - including giving information to potential employers, letter-writers, and people who are looking to update individual pieces of yt but don't know who they should talk to. It's not perfect, but it could help a bit.
Also, to the original point: I think that making tiers of contributors (i.e., "core" vs. "the teeming masses") is a recipe for resentment in the long term, as it becomes exclusive rather than inclusive. I can imagine a variety of conversations taking place, if only in somebody's head: "Core Developer X hasn't contributed in two years, and I've been really active for the past eighteen months - why are they still listed as a core developer and I'm not one?" or, "If the requirement is X changesets, I can game the system by making lots of very small changes and thus become a core developer." or, "If only the core developers get a say in the direction of the code, why should I even bother contributing?" And so on. Of course, it's reasonable to call yourself a core developer, and to ask letter-writers to mention that you are one, but establishing a formal set of requirements seems like it's asking for trouble.
--Brian
On Sun, Aug 31, 2014 at 9:07 AM, Britton Smith
wrote: Cameron,
I think this is a very valid issue that you raise. I have a couple concerns about creating a tier of "core" contributors on top of the member tier. I also have another idea at the end.
First, it is not clear to me the process by which we would establish the bar for a core contributor. I was comfortable with doing this rather ad-hoc for member status because it was designed to be inclusive and to establish a way that we could make decisions as a team. However, I don't think we can do that for this since it is creating a more exclusive group. If something like this is going to be created, then I think it needs to be done through the body of members that we will soon have. Otherwise, I don't know how it can be done fairly.
Second, I'm not sure that designating core contributors will be any more effective at properly crediting people for their work. At the end of the day, it will be another label that says in rather general terms that someone is very important to a project. I have been referring to myself as a core developer on job applications for a few years now and I don't think it's gotten me anything. Maybe that would change if there were an official definition of that term.
I would like to put forth another idea that could perhaps accomplish the same goal. Following the YTEP on governance, we are going to create a webpage on yt-project.org with an official definition of yt member status and a list of all members. I think it would be good if we allow those members to write bios for themselves that are linked to off of the member page. Those bios could contain anything you would want someone to know about your involvement in the project: how long you've been around, what features you've worked on, a link to your page on openhub.net, any other activities or things you've been a part of, whatever you want. That way you can not only be seen as a important person, but can get the specific credit that you deserve. Other people could even point out things that one might have missed. Maybe this will help the project seem less like a monolith and more like a lot of individual valuable pieces.
In conclusion, I am not totally opposed to core status, as long as it can be created in a fair and open way, but I would also really like to hear what people think about the bios.
Britton
On Sun, Aug 31, 2014 at 12:08 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I agree with Cameron that ultimately some way of ensuring recognition for the core developers (where len(core) < len(members)) is a good idea. Many (most?) of the big contributors to yt are in junior-level positions, and getting the recognition for their efforts will be important to getting into them more permanent positions. Unfortunately, for computational astrophysics, contributing to a software project doesn't carry as much weight as a scientific study in the eyes of the committees that do the hiring. I don't know what the right answer is, but I think Cameron's point needs to be discussed further, so that those people who are concerned/curious understand the incentive structure.
On Sat, Aug 30, 2014 at 4:18 PM, Cameron Hummels
wrote: On Sat, Aug 30, 2014 at 9:50 AM, Matthew Turk
wrote: I want to emphasize that the initial list of members Britton came up with (as he noted in the proposal) is only an *initial* list, and will hopefully very quickly expand to include less active "developers" who are nonetheless embedded in the community.
-Matt
And this is why I think we need a list of people who are regarded as "core" developers, to differentiate them from the what will likely be a very large list of "members". Right now from a professional standpoint, there is very little benefit from contributing to the code base, in that very few people recognize your contributions (ie a handful of other developers). Aside from a list of core developers that are highlighted on the webpage, or having a new yt paper come out, I don't see any other way in which this can be remedied. Perhaps others have ideas?
Brian
On Sat, Aug 30, 2014 at 9:30 AM, Britton Smith <
wrote: > > HI Brian, > > I couldn't agree more on having a documentation representative
> team meetings. In fact, I think this was even in my original draft, but I > somehow lost track of it. Thanks for bringing it up. I will get
> in there. A community representative is also a good idea, but I'm less sure > how that role would be filled. If anyone has any thoughts on that,
> do share. If it can't be figured out before the YTEP is accepted, we can > definitely amend it. Thanks, Brian! > > Britton > > > On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk < matthewturk@gmail.com> > wrote: >> >> Hi Brian, >> >> On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea
wrote: >> > Hi folks, >> > >> > Chiming in as somebody who is on the far periphery of yt development >> > (having >> > only contributed a couple of bug fixes/minor updates), I think >> > creation >> > of a formal governance structure is a significant positive step. Given >> > the >> > distributed nature of the development team some level of coordination >> > is >> > critical, and I also think that having a set of carefully-considered >> > standards about who gets a vote in terms of code direction, and how >> > many of >> > these votes are needed to enact substantial change (as opposed to the >> > ad-hoc >> > "preponderance of +1s from the mailing list" method) is an exceedingly >> > good >> > idea, as it will hopefully enhance the group's decision-making and make >> > it >> > more reflective. >> > >> > I also want to comment on the monthly team meetings. In addition to >> > posting >> > meeting minutes, perhaps the meeting coordinator or secretary could >> > organize >> > an agenda for the meeting and post it to the yt-dev mailing list a >> > couple of >> > days ahead of time? That way, people who are not participating in the >> > meeting, but who may have some input on the issues at hand, have an >> > opportunity to email suggestions. >> > >> > Finally, one other point: I can't help but notice that while the >> > technical >> > aspects of yt will be represented in these team meetings, there is no >> > *explicit* representation of the yt user community or yt documentation. >> > While in principle this isn't a problem -- Matt has made the
>> > times that the difference between user and developer isn't necessarily >> > meaningful in our context -- I do think that having somebody involved >> > whose >> > explicit responsibility is to consider the questions "how will
>> > impact >> > the broader yt user community?" and "what's missing from the >> > documentation >> > that could be added or improved?" may be beneficial. >> >> Yes, I agree. I actually have a few people I would submit as >> nominations for this role, but it seems to me it's certainly one
>> should be represented. >> >> > >> > Anyway, small nit-picks aside, I think this is a great idea. Thanks to >> > Britton for starting the ball rolling! >> > >> > --Brian >> > >> > >> > >> > >> > On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk < matthewturk@gmail.com> >> > wrote: >> >> >> >> Hi Britton, >> >> >> >> I think this is really, really important, and I'm really happy with >> >> the YTEP as it stands. >> >> >> >> We've only gotten feedback from a few people. I think it's really >> >> important to get both positive and negative feedback from
>> >> this -- even to the level of "geez, stop taking yourselves so >> >> seriously!" :) Do you think maybe an email to the yt-users mailing >> >> list would be productive? Or even directly writing to the
>> >> identified as "founding" members? >> >> >> >> -Matt >> >> >> >> On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith >> >>
>> >> wrote: >> >> > Hi everyone, >> >> > >> >> > I have just issued a pull request to the YTEP repository containing >> >> > an >> >> > initial draft of yt team guidelines. I encourage everyone to take a >> >> > look at >> >> > it and offer their feedback. In case you don't get the >> >> > notification, >> >> > the PR >> >> > can be viewed here: >> >> > >> >> > >> >> > https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras... >> >> > >> >> > Britton >> >> > >> >> > >> >> > On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith >> >> > >> >> > wrote: >> >> >> >> >> >> Hi Sam, >> >> >> >> >> >> This is an excellent point. I think it's important not to >> >> >> overburden a >> >> >> single person by being forever responsible for a large chunk of the >> >> >> code. I >> >> >> also think it's good to give as many as are willing an opportunity >> >> >> to >> >> >> share >> >> >> the role. Perhaps there is a team of people or subcommittee >> >> >> is >> >> >> responsible for figuring out who their representative is. This can >> >> >> be >> >> >> ironed out. >> >> >> >> >> >> I think we've gotten enough positive response to start
>> >> >> about a >> >> >> YTEP that lays it all out. I will start something this week, ask >> >> >> for >> >> >> feedback, and we can all develop this together. >> >> >> >> >> >> In the mean time, if you would still like to chime in on this >> >> >> discussion, >> >> >> please do so. >> >> >> Thanks, everyone. >> >> >> >> >> >> Britton >> >> >> >> >> >> >> >> >> On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman >> >> >>
>> >> >> wrote: >> >> >>> >> >> >>> Hi all, >> >> >>> >> >> >>> Britton -- I really like these ideas, and I like the member level >> >> >>> being >> >> >>> defined as write access. >> >> >>> >> >> >>> I'm a bit more concerned about the officers designation in terms >> >> >>> of >> >> >>> the >> >> >>> logistics of matching people with sections of the code. I could >> >> >>> see >> >> >>> something working where on a 6-month basis, each of the >> >> >>> in >> >> >>> yt are >> >> >>> assigned a lead. That lead isn't necessarily the person who has >> >> >>> written the >> >> >>> most in the area, but rather a person who is willing to keep track >> >> >>> of >> >> >>> that >> >> >>> area of the codebase for the next 6 months, so that when it comes >> >> >>> to >> >> >>> doing >> >> >>> releases, they are the ones that know what has changed and where >> >> >>> things are >> >> >>> not working well. Maybe that's too much of a process, but I also >> >> >>> think we >> >> >>> should be wary of assigning potentially long-lasting labels to >> >> >>> either >> >> >>> people >> >> >>> or code. Semi-regular meetings for this set of people would be >> >> >>> great. >> >> >>> >> >> >>> Anyways, I'm definitely a +1 on a YTEP for all of this, and look >> >> >>> forward >> >> >>> to hearing more! >> >> >>> >> >> >>> Cheers, >> >> >>> Sam >> >> >>> >> >> >>> >> >> >>> On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller >> >> >>>
>> >> >>> wrote: >> >> >>>> >> >> >>>> +1, absolutely. Right now, yt has a really high bus factor. I >> >> >>>> think >> >> >>>> this would help that a lot. >> >> >>>> >> >> >>>> >> >> >>>> On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone >> >> >>>> >> >> >>>> wrote: >> >> >>>>> >> >> >>>>> +1 as well on all suggestions >> >> >>>>> >> >> >>>>> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki < karraki@nmsu.edu> >> >> >>>>> > wrote: >> >> >>>>> > >> >> >>>>> > I wanted to put my strong +1 out there even though I don't >> >> >>>>> > respond >> >> >>>>> > often to dev emails. This sounds like a great direction for >> >> >>>>> > yt! >> >> >>>>> > >> >> >>>>> > -Kenza >> >> >>>>> > >> >> >>>>> > --- >> >> >>>>> > Kenza Arraki >> >> >>>>> > PhD candidate >> >> >>>>> > New Mexico State University >> >> >>>>> > Department of Astronomy >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale >> >> >>>>> > wrote: >> >> >>>>> >> these all sound like good ideas to me. Some simply operating >> >> >>>>> >> procedures, >> >> >>>>> >> like "don't merge your own pull requests" might be good too. >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith >> >> >>>>> >> >> >> >>>>> >> wrote: >> >> >>>>> >>> >> >> >>>>> >>> I'm very in favor of putting some official procedures into a >> >> >>>>> >>> YTEP. >> >> >>>>> >>> Having >> >> >>>>> >>> a codified process may also help with conflict resolution as >> >> >>>>> >>> well. >> >> >>>>> >>> >> >> >>>>> >>> Apache does something with their projects where developers >> >> >>>>> >>> who >> >> >>>>> >>> make >> >> >>>>> >>> sustained contribution are made "members" after nomination >> >> >>>>> >>> by >> >> >>>>> >>> another member >> >> >>>>> >>> and are given write access to the main repo. It's a small >> >> >>>>> >>> thing, >> >> >>>>> >>> but if we >> >> >>>>> >>> perhaps have an official definition of "yt member" in a YTEP >> >> >>>>> >>> with a >> >> >>>>> >>> posted >> >> >>>>> >>> list of members, it can be something people can point to as >> >> >>>>> >>> a >> >> >>>>> >>> way >> >> >>>>> >>> of >> >> >>>>> >>> demonstrating that they've done significant work on >> >> >>>>> >>> project. >> >> >>>>> >>> >> >> >>>>> >>> I think it might also be good to have officer-like
>> >> >>>>> >>> where >> >> >>>>> >>> people >> >> >>>>> >>> are representatives for various areas of the code, such as >> >> >>>>> >>> data >> >> >>>>> >>> structures, >> >> >>>>> >>> visualization, analysis_modules, etc. and to have >> >> >>>>> >>> semi-regular >> >> >>>>> >>> meeting of >> >> >>>>> >>> these people. This may be as much leadership as we need for >> >> >>>>> >>> now, >> >> >>>>> >>> just a >> >> >>>>> >>> group that meets on a schedule to make sure everyone's on >> >> >>>>> >>> the >> >> >>>>> >>> same >> >> >>>>> >>> page with >> >> >>>>> >>> releases and major development efforts. >> >> >>>>> >>> >> >> >>>>> >>> What do people think of something like this? >> >> >>>>> >>> >> >> >>>>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk >> >> >>>>> >>>
>> >> >>>>> >>> wrote: >> >> >>>>> >>>> >> >> >>>>> >>>> Hi Britton, >> >> >>>>> >>>> >> >> >>>>> >>>> Thanks for bringing this up -- it's a tough topic, but also >> >> >>>>> >>>> I >> >> >>>>> >>>> think >> >> >>>>> >>>> really important. At the WSSSPE conference last year, a >> >> >>>>> >>>> paper >> >> >>>>> >>>> was >> >> >>>>> >>>> submitted talking about the Apache model: >> >> >>>>> >>>> >> >> >>>>> >>>> >> >> >>>>> >>>> >> >> >>>>> >>>> >> >> >>>>> >>>> >> >> >>>>> >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... >> >> >>>>> >>>> >> >> >>>>> >>>> which talks about a lot of related topics. Apache does >> >> >>>>> >>>> some >> >> >>>>> >>>> interesting things. They use the word "meritocracy" which >> >> >>>>> >>>> I am >> >> >>>>> >>>> rather >> >> >>>>> >>>> -1 on using (see, for instance, >> >> >>>>> >>>> >> >> >>>>> >>>> >> >> >>>>> >>>> >> >> >>>>> >>>> >> >> >>>>> >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... >> >> >>>>> >>>> ) but I do think there is something to be said for a large >> >> >>>>> >>>> part >> >> >>>>> >>>> of >> >> >>>>> >>>> their methods of organization. >> >> >>>>> >>>> >> >> >>>>> >>>> Like you, I think we are overdue. I would like to >> >> >>>>> >>>> out >> >> >>>>> >>>> that, >> >> >>>>> >>>> for >> >> >>>>> >>>> all intents and purposes, you are *already* the ombudsman >> >> >>>>> >>>> for >> >> >>>>> >>>> the >> >> >>>>> >>>> yt >> >> >>>>> >>>> community. I don't think you're proposing we have a >> >> >>>>> >>>> committee >> >> >>>>> >>>> that >> >> >>>>> >>>> bosses everyone around, but rather one that enables a >> >> >>>>> >>>> larger >> >> >>>>> >>>> number of >> >> >>>>> >>>> people to have a say, particularly because yt has become >> >> >>>>> >>>> embedded >> >> >>>>> >>>> in >> >> >>>>> >>>> many of our scientific workflows and it touches a lot of >> >> >>>>> >>>> research >> >> >>>>> >>>> activities now. I like the idea of members. I like
>> >> >>>>> >>>> idea >> >> >>>>> >>>> of a >> >> >>>>> >>>> project management committee, but it's not clear to me how >> >> >>>>> >>>> that >> >> >>>>> >>>> would >> >> >>>>> >>>> work, or which decisions we have made recently that
>> >> >>>>> >>>> would >> >> >>>>> >>>> weigh >> >> >>>>> >>>> in on. I also really like the idea of having "code >> >> >>>>> >>>> liasons" to >> >> >>>>> >>>> different data platforms and/or communities, and the idea >> >> >>>>> >>>> of >> >> >>>>> >>>> having >> >> >>>>> >>>> people who are responsible for many different areas of the >> >> >>>>> >>>> code >> >> >>>>> >>>> and >> >> >>>>> >>>> codifying that in some way is quite attractive to me. >> >> >>>>> >>>> >> >> >>>>> >>>> For what it's worth, a few weeks ago I gave a
>> >> >>>>> >>>> on >> >> >>>>> >>>> my >> >> >>>>> >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). The >> >> >>>>> >>>> thing >> >> >>>>> >>>> is, >> >> >>>>> >>>> while I gave this presentation, it's just *my* vision -- it >> >> >>>>> >>>> is >> >> >>>>> >>>> not >> >> >>>>> >>>> necessarily anyone else's vision. And I think it's time we >> >> >>>>> >>>> have >> >> >>>>> >>>> some >> >> >>>>> >>>> method of taking into account a diverse set of opinions for >> >> >>>>> >>>> what >> >> >>>>> >>>> we as >> >> >>>>> >>>> a community can emphasize, how we resolve conflicts, and so >> >> >>>>> >>>> on >> >> >>>>> >>>> and >> >> >>>>> >>>> so >> >> >>>>> >>>> forth. >> >> >>>>> >>>> >> >> >>>>> >>>> Again, thanks for bringing this up. We need to have
>> >> >>>>> >>>> conversation. >> >> >>>>> >>>> >> >> >>>>> >>>> -Matt >> >> >>>>> >>>> >> >> >>>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith >> >> >>>>> >>>>
>> >> >>>>> >>>> wrote: >> >> >>>>> >>>>> Greeting yt developers, >> >> >>>>> >>>>> >> >> >>>>> >>>>> First, I want to congratulate everyone here on the >> >> >>>>> >>>>> successful >> >> >>>>> >>>>> release >> >> >>>>> >>>>> of yt-3.0. This was a massive effort on the part of so >> >> >>>>> >>>>> many >> >> >>>>> >>>>> and >> >> >>>>> >>>>> a >> >> >>>>> >>>>> true testament to the strength of this team. >> >> >>>>> >>>>> >> >> >>>>> >>>>> At the time of writing this, there are 78 members of the >> >> >>>>> >>>>> yt-dev >> >> >>>>> >>>>> mailing list. As someone who does most of their work in >> >> >>>>> >>>>> very >> >> >>>>> >>>>> small >> >> >>>>> >>>>> collaborations, this amazes me and make me very >> >> >>>>> >>>>> case >> >> >>>>> >>>>> you're >> >> >>>>> >>>>> wondering, the yt-users list has 268 members. >> >> >>>>> >>>>> >> >> >>>>> >>>>> As a project, yt has a significant amount of >> >> >>>>> >>>>> infrastructure: >> >> >>>>> >>>>> code >> >> >>>>> >>>>> review with pull requests, issue tracking, automated >> >> >>>>> >>>>> testing, >> >> >>>>> >>>>> emails >> >> >>>>> >>>>> lists, an IRC channel, enhancement proposals, workshops. >> >> >>>>> >>>>> All >> >> >>>>> >>>>> of >> >> >>>>> >>>>> this >> >> >>>>> >>>>> is evidence of our legitimacy as a Real Thing. However, >> >> >>>>> >>>>> one >> >> >>>>> >>>>> big >> >> >>>>> >>>>> missing piece is a system of governance. I don't know >> >> >>>>> >>>>> exactly >> >> >>>>> >>>>> what >> >> >>>>> >>>>> this means, but I have some ideas, which I will share >> >> >>>>> >>>>> below. >> >> >>>>> >>>>> What I >> >> >>>>> >>>>> want to do right now is to start a discussion that will, >> >> >>>>> >>>>> hopefully, >> >> >>>>> >>>>> include as many people as possible on this list. >> >> >>>>> >>>>> >> >> >>>>> >>>>> For me, governance means (roughly) the following: >> >> >>>>> >>>>> >> >> >>>>> >>>>> - a set of procedures in writing for how various
>> >> >>>>> >>>>> are to >> >> >>>>> >>>>> be >> >> >>>>> >>>>> done, such as acceptance of pull requests, releases, >> >> >>>>> >>>>> designating >> >> >>>>> >>>>> developers as core contributors, etc. >> >> >>>>> >>>>> >> >> >>>>> >>>>> - a governing body to make decisions and help guide
>> >> >>>>> >>>>> project. >> >> >>>>> >>>>> >> >> >>>>> >>>>> This accomplishes a number of things, which as a
>> >> >>>>> >>>>> think >> >> >>>>> >>>>> we >> >> >>>>> >>>>> need, such as: >> >> >>>>> >>>>> >> >> >>>>> >>>>> - overall stability of the project. >> >> >>>>> >>>>> >> >> >>>>> >>>>> - providing a system for conflict resolution. >> >> >>>>> >>>>> >> >> >>>>> >>>>> - maintaining the spirit of yt as a team effort. >> >> >>>>> >>>>> >> >> >>>>> >>>>> - providing a way for active contributors to get credit >> >> >>>>> >>>>> for >> >> >>>>> >>>>> their >> >> >>>>> >>>>> contribution in the form of official recognition. >> >> >>>>> >>>>> >> >> >>>>> >>>>> >> >> >>>>> >>>>> So, these are my initial thoughts, but I really
>> >> >>>>> >>>>> deserves a >> >> >>>>> >>>>> thorough discussion with as many people
>> >> >>>>> >>>>> possible. >> >> >>>>> >>>>> Please, think about what governance means to you, whether >> >> >>>>> >>>>> we >> >> >>>>> >>>>> need >> >> >>>>> >>>>> it, >> >> >>>>> >>>>> what it should be, and what we might get out of it, and >> >> >>>>> >>>>> share >> >> >>>>> >>>>> your >> >> >>>>> >>>>> thoughts over the next few days. I look forward to
brittonsmith@gmail.com> present at that back please that point many this that people on people that thinking main areas the positions point the they presentation this proud. In things the project I think this participating as this
>> >> >>>>> >>>>> discussion. >> >> >>>>> >>>>> >> >> >>>>> >>>>> Britton >> >> >>>>> >>>>> >> >> >>>>> >>>>> >> >> >>>>> >>>>> _______________________________________________ >> >> >>>>> >>>>> yt-dev mailing list >> >> >>>>> >>>>> yt-dev@lists.spacepope.org >> >> >>>>> >>>>> >> >> >>>>> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >>>>> >>>> _______________________________________________ >> >> >>>>> >>>> yt-dev mailing list >> >> >>>>> >>>> yt-dev@lists.spacepope.org >> >> >>>>> >>>> >> >> >>>>> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> >>> _______________________________________________ >> >> >>>>> >>> yt-dev mailing list >> >> >>>>> >>> yt-dev@lists.spacepope.org >> >> >>>>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >> >>>>> >> -- >> >> >>>>> >> Michael Zingale >> >> >>>>> >> Associate Professor >> >> >>>>> >> >> >> >>>>> >> Dept. of Physics & Astronomy • Stony Brook University • Stony >> >> >>>>> >> Brook, >> >> >>>>> >> NY >> >> >>>>> >> 11794-3800 >> >> >>>>> >> phone: 631-632-8225 >> >> >>>>> >> e-mail: Michael.Zingale@stonybrook.edu >> >> >>>>> >> web: http://www.astro.sunysb.edu/mzingale >> >> >>>>> >> >> >> >>>>> >> _______________________________________________ >> >> >>>>> >> yt-dev mailing list >> >> >>>>> >> yt-dev@lists.spacepope.org >> >> >>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >>>>> > _______________________________________________ >> >> >>>>> > yt-dev mailing list >> >> >>>>> > yt-dev@lists.spacepope.org >> >> >>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >>>>> _______________________________________________ >> >> >>>>> yt-dev mailing list >> >> >>>>> yt-dev@lists.spacepope.org >> >> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> yt-dev mailing list >> >> >>>> yt-dev@lists.spacepope.org >> >> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >>>> >> >> >>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> yt-dev mailing list >> >> >>> yt-dev@lists.spacepope.org >> >> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >>> >> >> >> >> >> > >> >> > >> >> > _______________________________________________ >> >> > yt-dev mailing list >> >> > yt-dev@lists.spacepope.org >> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> > >> >> _______________________________________________ >> >> yt-dev mailing list >> >> yt-dev@lists.spacepope.org >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > >> > >> > >> > _______________________________________________ >> > yt-dev mailing list >> > yt-dev@lists.spacepope.org >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Discussing the paper is out of scope for this thread, but I have begun
writing a yt 3 paper and was hoping to submit to the Journal of Open
Research Software, which is OA, published the WSSSPE collection, and will
avoid pigeon holing it as just an astro project.
On Sep 1, 2014 12:43 PM, "Brian O'Shea"
I hate to be the person that responds to my own post, but I also just remembered that there are some new (and old) journals that might be worth looking at, if one wants to publish the details of individual yt modules:
Astronomy and Computing: http://www.journals.elsevier.com/astronomy-and-computing/
Computational Astrophysics and Cosmology: http://www.comp-astrophys-cosmol.com/
Computer Physics Communications: http://www.journals.elsevier.com/computer-physics-communications/
Journal of Computational Physics: http://www.journals.elsevier.com/journal-of-computational-physics/
Publications of the Astronomical Society of the Pacific: http://www.press.uchicago.edu/ucp/journals/journal/pasp.html
If there's a truly innovative/useful piece of code, it might be worth writing it up in one of those. Some are really new (A&C, CompAC), but maybe worth trying out. These two new journals in particular seem to be designed for this sort of thing - in their charters they both mention data analysis and visualization software, and A&C states that this journal "accepts regular scientific articles and review articles, but will also consider manuscripts on new software and data releases of astronomical surveys, and "reports on practice" which describe the outcomes (positive and negative) of the practical application of informatics techniques within astronomy research and operations... Providing a sustainable link to data or source code is strongly encouraged." This seems to include a lot of what we do. And, of course, for new versions of yt, one could always imagine a follow-up paper in ApJS - the original yt ApJS method paper has 135 citations, as of today!
--Brian
On Mon, Sep 1, 2014 at 1:32 PM, Brian O'Shea
wrote: I'd like to second Britton's suggestion, and elaborate on them a bit. I've been on both sides of this particular issue - applying for jobs, and also looking at peoples' CVs for postdocs and faculty positions - and it's tough to get "credit" for software in the same way that you get credit for peer-reviewed journal articles, particularly if you're developing a community code like yt (or Enzo). But, it's easier when somebody has made well-defined and significant contributions to a particular project, has documented that in various ways (i.e., in a bio, Open HUB, your CV, etc.), and in particular when that person's letter-writers have talked about it in their letters and put it in context (i.e., "Dr. X was the primary developer of yt's widely-used Foo Generator module, wrote the underlying parallel infrastructure that allows it to strongly scale to 300 quintillion cores for arbitrarily small data volumes, and has been active in improving this code and supporting its use in the yt user community for the past four years. The Foo Generator has been a key part of the analysis done in at least 14 journal articles since its first release, the majority of which would not have been written were it not for Dr. X's contribution to yt. Furthermore, Dr. X has played key roles in the development of X, Y, and Z modules for Enzo, which demonstrates Dr. X's understanding of a wide variety of numerical algorithms, particularly for large-scale parallel computing."
So, my elaboration on Britton's suggestion is really to take advantage of the bios to lay out what peoples' major contributions have been to the yt project, which is useful for lots of purposes - including giving information to potential employers, letter-writers, and people who are looking to update individual pieces of yt but don't know who they should talk to. It's not perfect, but it could help a bit.
Also, to the original point: I think that making tiers of contributors (i.e., "core" vs. "the teeming masses") is a recipe for resentment in the long term, as it becomes exclusive rather than inclusive. I can imagine a variety of conversations taking place, if only in somebody's head: "Core Developer X hasn't contributed in two years, and I've been really active for the past eighteen months - why are they still listed as a core developer and I'm not one?" or, "If the requirement is X changesets, I can game the system by making lots of very small changes and thus become a core developer." or, "If only the core developers get a say in the direction of the code, why should I even bother contributing?" And so on. Of course, it's reasonable to call yourself a core developer, and to ask letter-writers to mention that you are one, but establishing a formal set of requirements seems like it's asking for trouble.
--Brian
On Sun, Aug 31, 2014 at 9:07 AM, Britton Smith
wrote: Cameron,
I think this is a very valid issue that you raise. I have a couple concerns about creating a tier of "core" contributors on top of the member tier. I also have another idea at the end.
First, it is not clear to me the process by which we would establish the bar for a core contributor. I was comfortable with doing this rather ad-hoc for member status because it was designed to be inclusive and to establish a way that we could make decisions as a team. However, I don't think we can do that for this since it is creating a more exclusive group. If something like this is going to be created, then I think it needs to be done through the body of members that we will soon have. Otherwise, I don't know how it can be done fairly.
Second, I'm not sure that designating core contributors will be any more effective at properly crediting people for their work. At the end of the day, it will be another label that says in rather general terms that someone is very important to a project. I have been referring to myself as a core developer on job applications for a few years now and I don't think it's gotten me anything. Maybe that would change if there were an official definition of that term.
I would like to put forth another idea that could perhaps accomplish the same goal. Following the YTEP on governance, we are going to create a webpage on yt-project.org with an official definition of yt member status and a list of all members. I think it would be good if we allow those members to write bios for themselves that are linked to off of the member page. Those bios could contain anything you would want someone to know about your involvement in the project: how long you've been around, what features you've worked on, a link to your page on openhub.net, any other activities or things you've been a part of, whatever you want. That way you can not only be seen as a important person, but can get the specific credit that you deserve. Other people could even point out things that one might have missed. Maybe this will help the project seem less like a monolith and more like a lot of individual valuable pieces.
In conclusion, I am not totally opposed to core status, as long as it can be created in a fair and open way, but I would also really like to hear what people think about the bios.
Britton
On Sun, Aug 31, 2014 at 12:08 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I agree with Cameron that ultimately some way of ensuring recognition for the core developers (where len(core) < len(members)) is a good idea. Many (most?) of the big contributors to yt are in junior-level positions, and getting the recognition for their efforts will be important to getting into them more permanent positions. Unfortunately, for computational astrophysics, contributing to a software project doesn't carry as much weight as a scientific study in the eyes of the committees that do the hiring. I don't know what the right answer is, but I think Cameron's point needs to be discussed further, so that those people who are concerned/curious understand the incentive structure.
On Sat, Aug 30, 2014 at 4:18 PM, Cameron Hummels
wrote: On Sat, Aug 30, 2014 at 9:50 AM, Matthew Turk
wrote: I want to emphasize that the initial list of members Britton came up with (as he noted in the proposal) is only an *initial* list, and will hopefully very quickly expand to include less active "developers" who are nonetheless embedded in the community.
-Matt
And this is why I think we need a list of people who are regarded as "core" developers, to differentiate them from the what will likely be a very large list of "members". Right now from a professional standpoint, there is very little benefit from contributing to the code base, in that very few people recognize your contributions (ie a handful of other developers). Aside from a list of core developers that are highlighted on the webpage, or having a new yt paper come out, I don't see any other way in which this can be remedied. Perhaps others have ideas?
> > Brian > > > > On Sat, Aug 30, 2014 at 9:30 AM, Britton Smith < brittonsmith@gmail.com> > wrote: >> >> HI Brian, >> >> I couldn't agree more on having a documentation representative present at >> team meetings. In fact, I think this was even in my original draft, but I >> somehow lost track of it. Thanks for bringing it up. I will get that back >> in there. A community representative is also a good idea, but I'm less sure >> how that role would be filled. If anyone has any thoughts on that, please >> do share. If it can't be figured out before the YTEP is accepted, we can >> definitely amend it. Thanks, Brian! >> >> Britton >> >> >> On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk < matthewturk@gmail.com> >> wrote: >>> >>> Hi Brian, >>> >>> On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea
wrote: >>> > Hi folks, >>> > >>> > Chiming in as somebody who is on the far periphery of yt development >>> > (having >>> > only contributed a couple of bug fixes/minor updates), I think that >>> > creation >>> > of a formal governance structure is a significant positive step. Given >>> > the >>> > distributed nature of the development team some level of coordination >>> > is >>> > critical, and I also think that having a set of carefully-considered >>> > standards about who gets a vote in terms of code direction, and how >>> > many of >>> > these votes are needed to enact substantial change (as opposed to the >>> > ad-hoc >>> > "preponderance of +1s from the mailing list" method) is an exceedingly >>> > good >>> > idea, as it will hopefully enhance the group's decision-making and make >>> > it >>> > more reflective. >>> > >>> > I also want to comment on the monthly team meetings. In addition to >>> > posting >>> > meeting minutes, perhaps the meeting coordinator or secretary could >>> > organize >>> > an agenda for the meeting and post it to the yt-dev mailing list a >>> > couple of >>> > days ahead of time? That way, people who are not participating in the >>> > meeting, but who may have some input on the issues at hand, have an >>> > opportunity to email suggestions. >>> > >>> > Finally, one other point: I can't help but notice that while the >>> > technical >>> > aspects of yt will be represented in these team meetings, there is no >>> > *explicit* representation of the yt user community or yt documentation. >>> > While in principle this isn't a problem -- Matt has made the point many >>> > times that the difference between user and developer isn't necessarily >>> > meaningful in our context -- I do think that having somebody involved >>> > whose >>> > explicit responsibility is to consider the questions "how will this >>> > impact >>> > the broader yt user community?" and "what's missing from the >>> > documentation >>> > that could be added or improved?" may be beneficial. >>> >>> Yes, I agree. I actually have a few people I would submit as >>> nominations for this role, but it seems to me it's certainly one that >>> should be represented. >>> >>> > >>> > Anyway, small nit-picks aside, I think this is a great idea. Thanks to >>> > Britton for starting the ball rolling! >>> > >>> > --Brian >>> > >>> > >>> > >>> > >>> > On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk < matthewturk@gmail.com> >>> > wrote: >>> >> >>> >> Hi Britton, >>> >> >>> >> I think this is really, really important, and I'm really happy with >>> >> the YTEP as it stands. >>> >> >>> >> We've only gotten feedback from a few people. I think it's really >>> >> important to get both positive and negative feedback from people on >>> >> this -- even to the level of "geez, stop taking yourselves so >>> >> seriously!" :) Do you think maybe an email to the yt-users mailing >>> >> list would be productive? Or even directly writing to the people >>> >> identified as "founding" members? >>> >> >>> >> -Matt >>> >> >>> >> On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith >>> >> >>> >> wrote: >>> >> > Hi everyone, >>> >> > >>> >> > I have just issued a pull request to the YTEP repository containing >>> >> > an >>> >> > initial draft of yt team guidelines. I encourage everyone to take a >>> >> > look at >>> >> > it and offer their feedback. In case you don't get the >>> >> > notification, >>> >> > the PR >>> >> > can be viewed here: >>> >> > >>> >> > >>> >> > https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras... >>> >> > >>> >> > Britton >>> >> > >>> >> > >>> >> > On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith >>> >> > >>> >> > wrote: >>> >> >> >>> >> >> Hi Sam, >>> >> >> >>> >> >> This is an excellent point. I think it's important not to >>> >> >> overburden a >>> >> >> single person by being forever responsible for a large chunk of the >>> >> >> code. I >>> >> >> also think it's good to give as many as are willing an opportunity >>> >> >> to >>> >> >> share >>> >> >> the role. Perhaps there is a team of people or subcommittee that >>> >> >> is >>> >> >> responsible for figuring out who their representative is. This can >>> >> >> be >>> >> >> ironed out. >>> >> >> >>> >> >> I think we've gotten enough positive response to start thinking >>> >> >> about a >>> >> >> YTEP that lays it all out. I will start something this week, ask >>> >> >> for >>> >> >> feedback, and we can all develop this together. >>> >> >> >>> >> >> In the mean time, if you would still like to chime in on this >>> >> >> discussion, >>> >> >> please do so. >>> >> >> Thanks, everyone. >>> >> >> >>> >> >> Britton >>> >> >> >>> >> >> >>> >> >> On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman >>> >> >> >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi all, >>> >> >>> >>> >> >>> Britton -- I really like these ideas, and I like the member level >>> >> >>> being >>> >> >>> defined as write access. >>> >> >>> >>> >> >>> I'm a bit more concerned about the officers designation in terms >>> >> >>> of >>> >> >>> the >>> >> >>> logistics of matching people with sections of the code. I could >>> >> >>> see >>> >> >>> something working where on a 6-month basis, each of the main areas >>> >> >>> in >>> >> >>> yt are >>> >> >>> assigned a lead. That lead isn't necessarily the person who has >>> >> >>> written the >>> >> >>> most in the area, but rather a person who is willing to keep track >>> >> >>> of >>> >> >>> that >>> >> >>> area of the codebase for the next 6 months, so that when it comes >>> >> >>> to >>> >> >>> doing >>> >> >>> releases, they are the ones that know what has changed and where >>> >> >>> things are >>> >> >>> not working well. Maybe that's too much of a process, but I also >>> >> >>> think we >>> >> >>> should be wary of assigning potentially long-lasting labels to >>> >> >>> either >>> >> >>> people >>> >> >>> or code. Semi-regular meetings for this set of people would be >>> >> >>> great. >>> >> >>> >>> >> >>> Anyways, I'm definitely a +1 on a YTEP for all of this, and look >>> >> >>> forward >>> >> >>> to hearing more! >>> >> >>> >>> >> >>> Cheers, >>> >> >>> Sam >>> >> >>> >>> >> >>> >>> >> >>> On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller >>> >> >>> >>> >> >>> wrote: >>> >> >>>> >>> >> >>>> +1, absolutely. Right now, yt has a really high bus factor. I >>> >> >>>> think >>> >> >>>> this would help that a lot. >>> >> >>>> >>> >> >>>> >>> >> >>>> On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone >>> >> >>>> >>> >> >>>> wrote: >>> >> >>>>> >>> >> >>>>> +1 as well on all suggestions >>> >> >>>>> >>> >> >>>>> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki < karraki@nmsu.edu> >>> >> >>>>> > wrote: >>> >> >>>>> > >>> >> >>>>> > I wanted to put my strong +1 out there even though I don't >>> >> >>>>> > respond >>> >> >>>>> > often to dev emails. This sounds like a great direction for >>> >> >>>>> > yt! >>> >> >>>>> > >>> >> >>>>> > -Kenza >>> >> >>>>> > >>> >> >>>>> > --- >>> >> >>>>> > Kenza Arraki >>> >> >>>>> > PhD candidate >>> >> >>>>> > New Mexico State University >>> >> >>>>> > Department of Astronomy >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale >>> >> >>>>> > wrote: >>> >> >>>>> >> these all sound like good ideas to me. Some simply operating >>> >> >>>>> >> procedures, >>> >> >>>>> >> like "don't merge your own pull requests" might be good too. >>> >> >>>>> >> >>> >> >>>>> >> >>> >> >>>>> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith >>> >> >>>>> >> >>> >> >>>>> >> wrote: >>> >> >>>>> >>> >>> >> >>>>> >>> I'm very in favor of putting some official procedures into a >>> >> >>>>> >>> YTEP. >>> >> >>>>> >>> Having >>> >> >>>>> >>> a codified process may also help with conflict resolution as >>> >> >>>>> >>> well. >>> >> >>>>> >>> >>> >> >>>>> >>> Apache does something with their projects where developers >>> >> >>>>> >>> who >>> >> >>>>> >>> make >>> >> >>>>> >>> sustained contribution are made "members" after nomination >>> >> >>>>> >>> by >>> >> >>>>> >>> another member >>> >> >>>>> >>> and are given write access to the main repo. It's a small >>> >> >>>>> >>> thing, >>> >> >>>>> >>> but if we >>> >> >>>>> >>> perhaps have an official definition of "yt member" in a YTEP >>> >> >>>>> >>> with a >>> >> >>>>> >>> posted >>> >> >>>>> >>> list of members, it can be something people can point to as >>> >> >>>>> >>> a >>> >> >>>>> >>> way >>> >> >>>>> >>> of >>> >> >>>>> >>> demonstrating that they've done significant work on the >>> >> >>>>> >>> project. >>> >> >>>>> >>> >>> >> >>>>> >>> I think it might also be good to have officer-like positions >>> >> >>>>> >>> where >>> >> >>>>> >>> people >>> >> >>>>> >>> are representatives for various areas of the code, such as >>> >> >>>>> >>> data >>> >> >>>>> >>> structures, >>> >> >>>>> >>> visualization, analysis_modules, etc. and to have >>> >> >>>>> >>> semi-regular >>> >> >>>>> >>> meeting of >>> >> >>>>> >>> these people. This may be as much leadership as we need for >>> >> >>>>> >>> now, >>> >> >>>>> >>> just a >>> >> >>>>> >>> group that meets on a schedule to make sure everyone's on >>> >> >>>>> >>> the >>> >> >>>>> >>> same >>> >> >>>>> >>> page with >>> >> >>>>> >>> releases and major development efforts. >>> >> >>>>> >>> >>> >> >>>>> >>> What do people think of something like this? >>> >> >>>>> >>> >>> >> >>>>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk >>> >> >>>>> >>> >>> >> >>>>> >>> wrote: >>> >> >>>>> >>>> >>> >> >>>>> >>>> Hi Britton, >>> >> >>>>> >>>> >>> >> >>>>> >>>> Thanks for bringing this up -- it's a tough topic, but also >>> >> >>>>> >>>> I >>> >> >>>>> >>>> think >>> >> >>>>> >>>> really important. At the WSSSPE conference last year, a >>> >> >>>>> >>>> paper >>> >> >>>>> >>>> was >>> >> >>>>> >>>> submitted talking about the Apache model: >>> >> >>>>> >>>> >>> >> >>>>> >>>> >>> >> >>>>> >>>> >>> >> >>>>> >>>> >>> >> >>>>> >>>> >>> >> >>>>> >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... >>> >> >>>>> >>>> >>> >> >>>>> >>>> which talks about a lot of related topics. Apache does >>> >> >>>>> >>>> some >>> >> >>>>> >>>> interesting things. They use the word "meritocracy" which >>> >> >>>>> >>>> I am >>> >> >>>>> >>>> rather >>> >> >>>>> >>>> -1 on using (see, for instance, >>> >> >>>>> >>>> >>> >> >>>>> >>>> >>> >> >>>>> >>>> >>> >> >>>>> >>>> >>> >> >>>>> >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... >>> >> >>>>> >>>> ) but I do think there is something to be said for a large >>> >> >>>>> >>>> part >>> >> >>>>> >>>> of >>> >> >>>>> >>>> their methods of organization. >>> >> >>>>> >>>> >>> >> >>>>> >>>> Like you, I think we are overdue. I would like to point >>> >> >>>>> >>>> out >>> >> >>>>> >>>> that, >>> >> >>>>> >>>> for >>> >> >>>>> >>>> all intents and purposes, you are *already* the ombudsman >>> >> >>>>> >>>> for >>> >> >>>>> >>>> the >>> >> >>>>> >>>> yt >>> >> >>>>> >>>> community. I don't think you're proposing we have a >>> >> >>>>> >>>> committee >>> >> >>>>> >>>> that >>> >> >>>>> >>>> bosses everyone around, but rather one that enables a >>> >> >>>>> >>>> larger >>> >> >>>>> >>>> number of >>> >> >>>>> >>>> people to have a say, particularly because yt has become >>> >> >>>>> >>>> embedded >>> >> >>>>> >>>> in >>> >> >>>>> >>>> many of our scientific workflows and it touches a lot of >>> >> >>>>> >>>> research >>> >> >>>>> >>>> activities now. I like the idea of members. I like the >>> >> >>>>> >>>> idea >>> >> >>>>> >>>> of a >>> >> >>>>> >>>> project management committee, but it's not clear to me how >>> >> >>>>> >>>> that >>> >> >>>>> >>>> would >>> >> >>>>> >>>> work, or which decisions we have made recently that they >>> >> >>>>> >>>> would >>> >> >>>>> >>>> weigh >>> >> >>>>> >>>> in on. I also really like the idea of having "code >>> >> >>>>> >>>> liasons" to >>> >> >>>>> >>>> different data platforms and/or communities, and the idea >>> >> >>>>> >>>> of >>> >> >>>>> >>>> having >>> >> >>>>> >>>> people who are responsible for many different areas of the >>> >> >>>>> >>>> code >>> >> >>>>> >>>> and >>> >> >>>>> >>>> codifying that in some way is quite attractive to me. >>> >> >>>>> >>>> >>> >> >>>>> >>>> For what it's worth, a few weeks ago I gave a presentation >>> >> >>>>> >>>> on >>> >> >>>>> >>>> my >>> >> >>>>> >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). The >>> >> >>>>> >>>> thing >>> >> >>>>> >>>> is, >>> >> >>>>> >>>> while I gave this presentation, it's just *my* vision -- it >>> >> >>>>> >>>> is >>> >> >>>>> >>>> not >>> >> >>>>> >>>> necessarily anyone else's vision. And I think it's time we >>> >> >>>>> >>>> have >>> >> >>>>> >>>> some >>> >> >>>>> >>>> method of taking into account a diverse set of opinions for >>> >> >>>>> >>>> what >>> >> >>>>> >>>> we as >>> >> >>>>> >>>> a community can emphasize, how we resolve conflicts, and so >>> >> >>>>> >>>> on >>> >> >>>>> >>>> and >>> >> >>>>> >>>> so >>> >> >>>>> >>>> forth. >>> >> >>>>> >>>> >>> >> >>>>> >>>> Again, thanks for bringing this up. We need to have this >>> >> >>>>> >>>> conversation. >>> >> >>>>> >>>> >>> >> >>>>> >>>> -Matt >>> >> >>>>> >>>> >>> >> >>>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith >>> >> >>>>> >>>> >>> >> >>>>> >>>> wrote: >>> >> >>>>> >>>>> Greeting yt developers, >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> First, I want to congratulate everyone here on the >>> >> >>>>> >>>>> successful >>> >> >>>>> >>>>> release >>> >> >>>>> >>>>> of yt-3.0. This was a massive effort on the part of so >>> >> >>>>> >>>>> many >>> >> >>>>> >>>>> and >>> >> >>>>> >>>>> a >>> >> >>>>> >>>>> true testament to the strength of this team. >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> At the time of writing this, there are 78 members of the >>> >> >>>>> >>>>> yt-dev >>> >> >>>>> >>>>> mailing list. As someone who does most of their work in >>> >> >>>>> >>>>> very >>> >> >>>>> >>>>> small >>> >> >>>>> >>>>> collaborations, this amazes me and make me very proud. In >>> >> >>>>> >>>>> case >>> >> >>>>> >>>>> you're >>> >> >>>>> >>>>> wondering, the yt-users list has 268 members. >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> As a project, yt has a significant amount of >>> >> >>>>> >>>>> infrastructure: >>> >> >>>>> >>>>> code >>> >> >>>>> >>>>> review with pull requests, issue tracking, automated >>> >> >>>>> >>>>> testing, >>> >> >>>>> >>>>> emails >>> >> >>>>> >>>>> lists, an IRC channel, enhancement proposals, workshops. >>> >> >>>>> >>>>> All >>> >> >>>>> >>>>> of >>> >> >>>>> >>>>> this >>> >> >>>>> >>>>> is evidence of our legitimacy as a Real Thing. However, >>> >> >>>>> >>>>> one >>> >> >>>>> >>>>> big >>> >> >>>>> >>>>> missing piece is a system of governance. I don't know >>> >> >>>>> >>>>> exactly >>> >> >>>>> >>>>> what >>> >> >>>>> >>>>> this means, but I have some ideas, which I will share >>> >> >>>>> >>>>> below. >>> >> >>>>> >>>>> What I >>> >> >>>>> >>>>> want to do right now is to start a discussion that will, >>> >> >>>>> >>>>> hopefully, >>> >> >>>>> >>>>> include as many people as possible on this list. >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> For me, governance means (roughly) the following: >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> - a set of procedures in writing for how various things >>> >> >>>>> >>>>> are to >>> >> >>>>> >>>>> be >>> >> >>>>> >>>>> done, such as acceptance of pull requests, releases, >>> >> >>>>> >>>>> designating >>> >> >>>>> >>>>> developers as core contributors, etc. >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> - a governing body to make decisions and help guide the >>> >> >>>>> >>>>> project. >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> This accomplishes a number of things, which as a project I >>> >> >>>>> >>>>> think >>> >> >>>>> >>>>> we >>> >> >>>>> >>>>> need, such as: >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> - overall stability of the project. >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> - providing a system for conflict resolution. >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> - maintaining the spirit of yt as a team effort. >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> - providing a way for active contributors to get credit >>> >> >>>>> >>>>> for >>> >> >>>>> >>>>> their >>> >> >>>>> >>>>> contribution in the form of official recognition. >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> So, these are my initial thoughts, but I really think this >>> >> >>>>> >>>>> deserves a >>> >> >>>>> >>>>> thorough discussion with as many people participating as >>> >> >>>>> >>>>> possible. >>> >> >>>>> >>>>> Please, think about what governance means to you, whether >>> >> >>>>> >>>>> we >>> >> >>>>> >>>>> need >>> >> >>>>> >>>>> it, >>> >> >>>>> >>>>> what it should be, and what we might get out of it, and >>> >> >>>>> >>>>> share >>> >> >>>>> >>>>> your >>> >> >>>>> >>>>> thoughts over the next few days. I look forward to this >>> >> >>>>> >>>>> discussion. >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> Britton >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> _______________________________________________ >>> >> >>>>> >>>>> yt-dev mailing list >>> >> >>>>> >>>>> yt-dev@lists.spacepope.org >>> >> >>>>> >>>>> >>> >> >>>>> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> >>>>> >>>> _______________________________________________ >>> >> >>>>> >>>> yt-dev mailing list >>> >> >>>>> >>>> yt-dev@lists.spacepope.org >>> >> >>>>> >>>> >>> >> >>>>> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> >>>>> >>> >>> >> >>>>> >>> >>> >> >>>>> >>> >>> >> >>>>> >>> _______________________________________________ >>> >> >>>>> >>> yt-dev mailing list >>> >> >>>>> >>> yt-dev@lists.spacepope.org >>> >> >>>>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> >>>>> >> >>> >> >>>>> >> >>> >> >>>>> >> >>> >> >>>>> >> -- >>> >> >>>>> >> Michael Zingale >>> >> >>>>> >> Associate Professor >>> >> >>>>> >> >>> >> >>>>> >> Dept. of Physics & Astronomy • Stony Brook University • Stony >>> >> >>>>> >> Brook, >>> >> >>>>> >> NY >>> >> >>>>> >> 11794-3800 >>> >> >>>>> >> phone: 631-632-8225 >>> >> >>>>> >> e-mail: Michael.Zingale@stonybrook.edu >>> >> >>>>> >> web: http://www.astro.sunysb.edu/mzingale >>> >> >>>>> >> >>> >> >>>>> >> _______________________________________________ >>> >> >>>>> >> yt-dev mailing list >>> >> >>>>> >> yt-dev@lists.spacepope.org >>> >> >>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> >>>>> > _______________________________________________ >>> >> >>>>> > yt-dev mailing list >>> >> >>>>> > yt-dev@lists.spacepope.org >>> >> >>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> >>>>> _______________________________________________ >>> >> >>>>> yt-dev mailing list >>> >> >>>>> yt-dev@lists.spacepope.org >>> >> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> _______________________________________________ >>> >> >>>> yt-dev mailing list >>> >> >>>> yt-dev@lists.spacepope.org >>> >> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> >>>> >>> >> >>> >>> >> >>> >>> >> >>> _______________________________________________ >>> >> >>> yt-dev mailing list >>> >> >>> yt-dev@lists.spacepope.org >>> >> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> >>> >>> >> >> >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > yt-dev mailing list >>> >> > yt-dev@lists.spacepope.org >>> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> > >>> >> _______________________________________________ >>> >> yt-dev mailing list >>> >> yt-dev@lists.spacepope.org >>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> > >>> > >>> > >>> > _______________________________________________ >>> > yt-dev mailing list >>> > yt-dev@lists.spacepope.org >>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> > >>> _______________________________________________ >>> yt-dev mailing list >>> yt-dev@lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >> >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org -- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
(And I hope it goes without saying that this paper would have an enormous
author list.)
On Sep 1, 2014 12:49 PM, "Matthew Turk"
Discussing the paper is out of scope for this thread, but I have begun writing a yt 3 paper and was hoping to submit to the Journal of Open Research Software, which is OA, published the WSSSPE collection, and will avoid pigeon holing it as just an astro project. On Sep 1, 2014 12:43 PM, "Brian O'Shea"
wrote: I hate to be the person that responds to my own post, but I also just remembered that there are some new (and old) journals that might be worth looking at, if one wants to publish the details of individual yt modules:
Astronomy and Computing: http://www.journals.elsevier.com/astronomy-and-computing/
Computational Astrophysics and Cosmology: http://www.comp-astrophys-cosmol.com/
Computer Physics Communications: http://www.journals.elsevier.com/computer-physics-communications/
Journal of Computational Physics: http://www.journals.elsevier.com/journal-of-computational-physics/
Publications of the Astronomical Society of the Pacific: http://www.press.uchicago.edu/ucp/journals/journal/pasp.html
If there's a truly innovative/useful piece of code, it might be worth writing it up in one of those. Some are really new (A&C, CompAC), but maybe worth trying out. These two new journals in particular seem to be designed for this sort of thing - in their charters they both mention data analysis and visualization software, and A&C states that this journal "accepts regular scientific articles and review articles, but will also consider manuscripts on new software and data releases of astronomical surveys, and "reports on practice" which describe the outcomes (positive and negative) of the practical application of informatics techniques within astronomy research and operations... Providing a sustainable link to data or source code is strongly encouraged." This seems to include a lot of what we do. And, of course, for new versions of yt, one could always imagine a follow-up paper in ApJS - the original yt ApJS method paper has 135 citations, as of today!
--Brian
On Mon, Sep 1, 2014 at 1:32 PM, Brian O'Shea
wrote: I'd like to second Britton's suggestion, and elaborate on them a bit. I've been on both sides of this particular issue - applying for jobs, and also looking at peoples' CVs for postdocs and faculty positions - and it's tough to get "credit" for software in the same way that you get credit for peer-reviewed journal articles, particularly if you're developing a community code like yt (or Enzo). But, it's easier when somebody has made well-defined and significant contributions to a particular project, has documented that in various ways (i.e., in a bio, Open HUB, your CV, etc.), and in particular when that person's letter-writers have talked about it in their letters and put it in context (i.e., "Dr. X was the primary developer of yt's widely-used Foo Generator module, wrote the underlying parallel infrastructure that allows it to strongly scale to 300 quintillion cores for arbitrarily small data volumes, and has been active in improving this code and supporting its use in the yt user community for the past four years. The Foo Generator has been a key part of the analysis done in at least 14 journal articles since its first release, the majority of which would not have been written were it not for Dr. X's contribution to yt. Furthermore, Dr. X has played key roles in the development of X, Y, and Z modules for Enzo, which demonstrates Dr. X's understanding of a wide variety of numerical algorithms, particularly for large-scale parallel computing."
So, my elaboration on Britton's suggestion is really to take advantage of the bios to lay out what peoples' major contributions have been to the yt project, which is useful for lots of purposes - including giving information to potential employers, letter-writers, and people who are looking to update individual pieces of yt but don't know who they should talk to. It's not perfect, but it could help a bit.
Also, to the original point: I think that making tiers of contributors (i.e., "core" vs. "the teeming masses") is a recipe for resentment in the long term, as it becomes exclusive rather than inclusive. I can imagine a variety of conversations taking place, if only in somebody's head: "Core Developer X hasn't contributed in two years, and I've been really active for the past eighteen months - why are they still listed as a core developer and I'm not one?" or, "If the requirement is X changesets, I can game the system by making lots of very small changes and thus become a core developer." or, "If only the core developers get a say in the direction of the code, why should I even bother contributing?" And so on. Of course, it's reasonable to call yourself a core developer, and to ask letter-writers to mention that you are one, but establishing a formal set of requirements seems like it's asking for trouble.
--Brian
On Sun, Aug 31, 2014 at 9:07 AM, Britton Smith
wrote: Cameron,
I think this is a very valid issue that you raise. I have a couple concerns about creating a tier of "core" contributors on top of the member tier. I also have another idea at the end.
First, it is not clear to me the process by which we would establish the bar for a core contributor. I was comfortable with doing this rather ad-hoc for member status because it was designed to be inclusive and to establish a way that we could make decisions as a team. However, I don't think we can do that for this since it is creating a more exclusive group. If something like this is going to be created, then I think it needs to be done through the body of members that we will soon have. Otherwise, I don't know how it can be done fairly.
Second, I'm not sure that designating core contributors will be any more effective at properly crediting people for their work. At the end of the day, it will be another label that says in rather general terms that someone is very important to a project. I have been referring to myself as a core developer on job applications for a few years now and I don't think it's gotten me anything. Maybe that would change if there were an official definition of that term.
I would like to put forth another idea that could perhaps accomplish the same goal. Following the YTEP on governance, we are going to create a webpage on yt-project.org with an official definition of yt member status and a list of all members. I think it would be good if we allow those members to write bios for themselves that are linked to off of the member page. Those bios could contain anything you would want someone to know about your involvement in the project: how long you've been around, what features you've worked on, a link to your page on openhub.net, any other activities or things you've been a part of, whatever you want. That way you can not only be seen as a important person, but can get the specific credit that you deserve. Other people could even point out things that one might have missed. Maybe this will help the project seem less like a monolith and more like a lot of individual valuable pieces.
In conclusion, I am not totally opposed to core status, as long as it can be created in a fair and open way, but I would also really like to hear what people think about the bios.
Britton
On Sun, Aug 31, 2014 at 12:08 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I agree with Cameron that ultimately some way of ensuring recognition for the core developers (where len(core) < len(members)) is a good idea. Many (most?) of the big contributors to yt are in junior-level positions, and getting the recognition for their efforts will be important to getting into them more permanent positions. Unfortunately, for computational astrophysics, contributing to a software project doesn't carry as much weight as a scientific study in the eyes of the committees that do the hiring. I don't know what the right answer is, but I think Cameron's point needs to be discussed further, so that those people who are concerned/curious understand the incentive structure.
On Sat, Aug 30, 2014 at 4:18 PM, Cameron Hummels
wrote: On Sat, Aug 30, 2014 at 9:50 AM, Matthew Turk
wrote: > > > I want to emphasize that the initial list of members Britton came up > with (as he noted in the proposal) is only an *initial* list, and > will > hopefully very quickly expand to include less active "developers" who > are nonetheless embedded in the community. > > -Matt > > And this is why I think we need a list of people who are regarded as "core" developers, to differentiate them from the what will likely be a very large list of "members". Right now from a professional standpoint, there is very little benefit from contributing to the code base, in that very few people recognize your contributions (ie a handful of other developers). Aside from a list of core developers that are highlighted on the webpage, or having a new yt paper come out, I don't see any other way in which this can be remedied. Perhaps others have ideas?
> > > > Brian > > > > > > > > On Sat, Aug 30, 2014 at 9:30 AM, Britton Smith < > brittonsmith@gmail.com> > > wrote: > >> > >> HI Brian, > >> > >> I couldn't agree more on having a documentation representative > present at > >> team meetings. In fact, I think this was even in my original > draft, but I > >> somehow lost track of it. Thanks for bringing it up. I will get > that back > >> in there. A community representative is also a good idea, but > I'm less sure > >> how that role would be filled. If anyone has any thoughts on > that, please > >> do share. If it can't be figured out before the YTEP is > accepted, we can > >> definitely amend it. Thanks, Brian! > >> > >> Britton > >> > >> > >> On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk < > matthewturk@gmail.com> > >> wrote: > >>> > >>> Hi Brian, > >>> > >>> On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea
> wrote: > >>> > Hi folks, > >>> > > >>> > Chiming in as somebody who is on the far periphery of yt > development > >>> > (having > >>> > only contributed a couple of bug fixes/minor updates), I think > that > >>> > creation > >>> > of a formal governance structure is a significant positive > step. Given > >>> > the > >>> > distributed nature of the development team some level of > coordination > >>> > is > >>> > critical, and I also think that having a set of > carefully-considered > >>> > standards about who gets a vote in terms of code direction, > and how > >>> > many of > >>> > these votes are needed to enact substantial change (as opposed > to the > >>> > ad-hoc > >>> > "preponderance of +1s from the mailing list" method) is an > exceedingly > >>> > good > >>> > idea, as it will hopefully enhance the group's decision-making > and make > >>> > it > >>> > more reflective. > >>> > > >>> > I also want to comment on the monthly team meetings. In > addition to > >>> > posting > >>> > meeting minutes, perhaps the meeting coordinator or secretary > could > >>> > organize > >>> > an agenda for the meeting and post it to the yt-dev mailing > list a > >>> > couple of > >>> > days ahead of time? That way, people who are not > participating in the > >>> > meeting, but who may have some input on the issues at hand, > have an > >>> > opportunity to email suggestions. > >>> > > >>> > Finally, one other point: I can't help but notice that while > the > >>> > technical > >>> > aspects of yt will be represented in these team meetings, > there is no > >>> > *explicit* representation of the yt user community or yt > documentation. > >>> > While in principle this isn't a problem -- Matt has made the > point many > >>> > times that the difference between user and developer isn't > necessarily > >>> > meaningful in our context -- I do think that having somebody > involved > >>> > whose > >>> > explicit responsibility is to consider the questions "how will > this > >>> > impact > >>> > the broader yt user community?" and "what's missing from the > >>> > documentation > >>> > that could be added or improved?" may be beneficial. > >>> > >>> Yes, I agree. I actually have a few people I would submit as > >>> nominations for this role, but it seems to me it's certainly one > that > >>> should be represented. > >>> > >>> > > >>> > Anyway, small nit-picks aside, I think this is a great idea. > Thanks to > >>> > Britton for starting the ball rolling! > >>> > > >>> > --Brian > >>> > > >>> > > >>> > > >>> > > >>> > On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk < > matthewturk@gmail.com> > >>> > wrote: > >>> >> > >>> >> Hi Britton, > >>> >> > >>> >> I think this is really, really important, and I'm really > happy with > >>> >> the YTEP as it stands. > >>> >> > >>> >> We've only gotten feedback from a few people. I think it's > really > >>> >> important to get both positive and negative feedback from > people on > >>> >> this -- even to the level of "geez, stop taking yourselves so > >>> >> seriously!" :) Do you think maybe an email to the yt-users > mailing > >>> >> list would be productive? Or even directly writing to the > people > >>> >> identified as "founding" members? > >>> >> > >>> >> -Matt > >>> >> > >>> >> On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith > >>> >> > >>> >> wrote: > >>> >> > Hi everyone, > >>> >> > > >>> >> > I have just issued a pull request to the YTEP repository > containing > >>> >> > an > >>> >> > initial draft of yt team guidelines. I encourage everyone > to take a > >>> >> > look at > >>> >> > it and offer their feedback. In case you don't get the > >>> >> > notification, > >>> >> > the PR > >>> >> > can be viewed here: > >>> >> > > >>> >> > > >>> >> > > https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras... > >>> >> > > >>> >> > Britton > >>> >> > > >>> >> > > >>> >> > On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith > >>> >> > > >>> >> > wrote: > >>> >> >> > >>> >> >> Hi Sam, > >>> >> >> > >>> >> >> This is an excellent point. I think it's important not to > >>> >> >> overburden a > >>> >> >> single person by being forever responsible for a large > chunk of the > >>> >> >> code. I > >>> >> >> also think it's good to give as many as are willing an > opportunity > >>> >> >> to > >>> >> >> share > >>> >> >> the role. Perhaps there is a team of people or > subcommittee that > >>> >> >> is > >>> >> >> responsible for figuring out who their representative is. > This can > >>> >> >> be > >>> >> >> ironed out. > >>> >> >> > >>> >> >> I think we've gotten enough positive response to start > thinking > >>> >> >> about a > >>> >> >> YTEP that lays it all out. I will start something this > week, ask > >>> >> >> for > >>> >> >> feedback, and we can all develop this together. > >>> >> >> > >>> >> >> In the mean time, if you would still like to chime in on > this > >>> >> >> discussion, > >>> >> >> please do so. > >>> >> >> Thanks, everyone. > >>> >> >> > >>> >> >> Britton > >>> >> >> > >>> >> >> > >>> >> >> On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman > >>> >> >> > >>> >> >> wrote: > >>> >> >>> > >>> >> >>> Hi all, > >>> >> >>> > >>> >> >>> Britton -- I really like these ideas, and I like the > member level > >>> >> >>> being > >>> >> >>> defined as write access. > >>> >> >>> > >>> >> >>> I'm a bit more concerned about the officers designation > in terms > >>> >> >>> of > >>> >> >>> the > >>> >> >>> logistics of matching people with sections of the code. I > could > >>> >> >>> see > >>> >> >>> something working where on a 6-month basis, each of the > main areas > >>> >> >>> in > >>> >> >>> yt are > >>> >> >>> assigned a lead. That lead isn't necessarily the person > who has > >>> >> >>> written the > >>> >> >>> most in the area, but rather a person who is willing to > keep track > >>> >> >>> of > >>> >> >>> that > >>> >> >>> area of the codebase for the next 6 months, so that when > it comes > >>> >> >>> to > >>> >> >>> doing > >>> >> >>> releases, they are the ones that know what has changed > and where > >>> >> >>> things are > >>> >> >>> not working well. Maybe that's too much of a process, > but I also > >>> >> >>> think we > >>> >> >>> should be wary of assigning potentially long-lasting > labels to > >>> >> >>> either > >>> >> >>> people > >>> >> >>> or code. Semi-regular meetings for this set of people > would be > >>> >> >>> great. > >>> >> >>> > >>> >> >>> Anyways, I'm definitely a +1 on a YTEP for all of this, > and look > >>> >> >>> forward > >>> >> >>> to hearing more! > >>> >> >>> > >>> >> >>> Cheers, > >>> >> >>> Sam > >>> >> >>> > >>> >> >>> > >>> >> >>> On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller > >>> >> >>> > >>> >> >>> wrote: > >>> >> >>>> > >>> >> >>>> +1, absolutely. Right now, yt has a really high bus > factor. I > >>> >> >>>> think > >>> >> >>>> this would help that a lot. > >>> >> >>>> > >>> >> >>>> > >>> >> >>>> On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone > >>> >> >>>> > >>> >> >>>> wrote: > >>> >> >>>>> > >>> >> >>>>> +1 as well on all suggestions > >>> >> >>>>> > >>> >> >>>>> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki < > karraki@nmsu.edu> > >>> >> >>>>> > wrote: > >>> >> >>>>> > > >>> >> >>>>> > I wanted to put my strong +1 out there even though I > don't > >>> >> >>>>> > respond > >>> >> >>>>> > often to dev emails. This sounds like a great > direction for > >>> >> >>>>> > yt! > >>> >> >>>>> > > >>> >> >>>>> > -Kenza > >>> >> >>>>> > > >>> >> >>>>> > --- > >>> >> >>>>> > Kenza Arraki > >>> >> >>>>> > PhD candidate > >>> >> >>>>> > New Mexico State University > >>> >> >>>>> > Department of Astronomy > >>> >> >>>>> > > >>> >> >>>>> > > >>> >> >>>>> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale > >>> >> >>>>> > wrote: > >>> >> >>>>> >> these all sound like good ideas to me. Some simply > operating > >>> >> >>>>> >> procedures, > >>> >> >>>>> >> like "don't merge your own pull requests" might be > good too. > >>> >> >>>>> >> > >>> >> >>>>> >> > >>> >> >>>>> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith > >>> >> >>>>> >> > >>> >> >>>>> >> wrote: > >>> >> >>>>> >>> > >>> >> >>>>> >>> I'm very in favor of putting some official > procedures into a > >>> >> >>>>> >>> YTEP. > >>> >> >>>>> >>> Having > >>> >> >>>>> >>> a codified process may also help with conflict > resolution as > >>> >> >>>>> >>> well. > >>> >> >>>>> >>> > >>> >> >>>>> >>> Apache does something with their projects where > developers > >>> >> >>>>> >>> who > >>> >> >>>>> >>> make > >>> >> >>>>> >>> sustained contribution are made "members" after > nomination > >>> >> >>>>> >>> by > >>> >> >>>>> >>> another member > >>> >> >>>>> >>> and are given write access to the main repo. It's > a small > >>> >> >>>>> >>> thing, > >>> >> >>>>> >>> but if we > >>> >> >>>>> >>> perhaps have an official definition of "yt member" > in a YTEP > >>> >> >>>>> >>> with a > >>> >> >>>>> >>> posted > >>> >> >>>>> >>> list of members, it can be something people can > point to as > >>> >> >>>>> >>> a > >>> >> >>>>> >>> way > >>> >> >>>>> >>> of > >>> >> >>>>> >>> demonstrating that they've done significant work on > the > >>> >> >>>>> >>> project. > >>> >> >>>>> >>> > >>> >> >>>>> >>> I think it might also be good to have officer-like > positions > >>> >> >>>>> >>> where > >>> >> >>>>> >>> people > >>> >> >>>>> >>> are representatives for various areas of the code, > such as > >>> >> >>>>> >>> data > >>> >> >>>>> >>> structures, > >>> >> >>>>> >>> visualization, analysis_modules, etc. and to have > >>> >> >>>>> >>> semi-regular > >>> >> >>>>> >>> meeting of > >>> >> >>>>> >>> these people. This may be as much leadership as we > need for > >>> >> >>>>> >>> now, > >>> >> >>>>> >>> just a > >>> >> >>>>> >>> group that meets on a schedule to make sure > everyone's on > >>> >> >>>>> >>> the > >>> >> >>>>> >>> same > >>> >> >>>>> >>> page with > >>> >> >>>>> >>> releases and major development efforts. > >>> >> >>>>> >>> > >>> >> >>>>> >>> What do people think of something like this? > >>> >> >>>>> >>> > >>> >> >>>>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk > >>> >> >>>>> >>> > >>> >> >>>>> >>> wrote: > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> Hi Britton, > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> Thanks for bringing this up -- it's a tough topic, > but also > >>> >> >>>>> >>>> I > >>> >> >>>>> >>>> think > >>> >> >>>>> >>>> really important. At the WSSSPE conference last > year, a > >>> >> >>>>> >>>> paper > >>> >> >>>>> >>>> was > >>> >> >>>>> >>>> submitted talking about the Apache model: > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> > http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> which talks about a lot of related topics. Apache > does > >>> >> >>>>> >>>> some > >>> >> >>>>> >>>> interesting things. They use the word > "meritocracy" which > >>> >> >>>>> >>>> I am > >>> >> >>>>> >>>> rather > >>> >> >>>>> >>>> -1 on using (see, for instance, > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> > http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... > >>> >> >>>>> >>>> ) but I do think there is something to be said for > a large > >>> >> >>>>> >>>> part > >>> >> >>>>> >>>> of > >>> >> >>>>> >>>> their methods of organization. > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> Like you, I think we are overdue. I would like to > point > >>> >> >>>>> >>>> out > >>> >> >>>>> >>>> that, > >>> >> >>>>> >>>> for > >>> >> >>>>> >>>> all intents and purposes, you are *already* the > ombudsman > >>> >> >>>>> >>>> for > >>> >> >>>>> >>>> the > >>> >> >>>>> >>>> yt > >>> >> >>>>> >>>> community. I don't think you're proposing we have > a > >>> >> >>>>> >>>> committee > >>> >> >>>>> >>>> that > >>> >> >>>>> >>>> bosses everyone around, but rather one that > enables a > >>> >> >>>>> >>>> larger > >>> >> >>>>> >>>> number of > >>> >> >>>>> >>>> people to have a say, particularly because yt has > become > >>> >> >>>>> >>>> embedded > >>> >> >>>>> >>>> in > >>> >> >>>>> >>>> many of our scientific workflows and it touches a > lot of > >>> >> >>>>> >>>> research > >>> >> >>>>> >>>> activities now. I like the idea of members. I > like the > >>> >> >>>>> >>>> idea > >>> >> >>>>> >>>> of a > >>> >> >>>>> >>>> project management committee, but it's not clear > to me how > >>> >> >>>>> >>>> that > >>> >> >>>>> >>>> would > >>> >> >>>>> >>>> work, or which decisions we have made recently > that they > >>> >> >>>>> >>>> would > >>> >> >>>>> >>>> weigh > >>> >> >>>>> >>>> in on. I also really like the idea of having "code > >>> >> >>>>> >>>> liasons" to > >>> >> >>>>> >>>> different data platforms and/or communities, and > the idea > >>> >> >>>>> >>>> of > >>> >> >>>>> >>>> having > >>> >> >>>>> >>>> people who are responsible for many different > areas of the > >>> >> >>>>> >>>> code > >>> >> >>>>> >>>> and > >>> >> >>>>> >>>> codifying that in some way is quite attractive to > me. > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> For what it's worth, a few weeks ago I gave a > presentation > >>> >> >>>>> >>>> on > >>> >> >>>>> >>>> my > >>> >> >>>>> >>>> "vision" for the future of yt ( > http://goo.gl/JKt6MA). The > >>> >> >>>>> >>>> thing > >>> >> >>>>> >>>> is, > >>> >> >>>>> >>>> while I gave this presentation, it's just *my* > vision -- it > >>> >> >>>>> >>>> is > >>> >> >>>>> >>>> not > >>> >> >>>>> >>>> necessarily anyone else's vision. And I think > it's time we > >>> >> >>>>> >>>> have > >>> >> >>>>> >>>> some > >>> >> >>>>> >>>> method of taking into account a diverse set of > opinions for > >>> >> >>>>> >>>> what > >>> >> >>>>> >>>> we as > >>> >> >>>>> >>>> a community can emphasize, how we resolve > conflicts, and so > >>> >> >>>>> >>>> on > >>> >> >>>>> >>>> and > >>> >> >>>>> >>>> so > >>> >> >>>>> >>>> forth. > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> Again, thanks for bringing this up. We need to > have this > >>> >> >>>>> >>>> conversation. > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> -Matt > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> wrote: > >>> >> >>>>> >>>>> Greeting yt developers, > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> First, I want to congratulate everyone here on the > >>> >> >>>>> >>>>> successful > >>> >> >>>>> >>>>> release > >>> >> >>>>> >>>>> of yt-3.0. This was a massive effort on the part > of so > >>> >> >>>>> >>>>> many > >>> >> >>>>> >>>>> and > >>> >> >>>>> >>>>> a > >>> >> >>>>> >>>>> true testament to the strength of this team. > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> At the time of writing this, there are 78 members > of the > >>> >> >>>>> >>>>> yt-dev > >>> >> >>>>> >>>>> mailing list. As someone who does most of their > work in > >>> >> >>>>> >>>>> very > >>> >> >>>>> >>>>> small > >>> >> >>>>> >>>>> collaborations, this amazes me and make me very > proud. In > >>> >> >>>>> >>>>> case > >>> >> >>>>> >>>>> you're > >>> >> >>>>> >>>>> wondering, the yt-users list has 268 members. > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> As a project, yt has a significant amount of > >>> >> >>>>> >>>>> infrastructure: > >>> >> >>>>> >>>>> code > >>> >> >>>>> >>>>> review with pull requests, issue tracking, > automated > >>> >> >>>>> >>>>> testing, > >>> >> >>>>> >>>>> emails > >>> >> >>>>> >>>>> lists, an IRC channel, enhancement proposals, > workshops. > >>> >> >>>>> >>>>> All > >>> >> >>>>> >>>>> of > >>> >> >>>>> >>>>> this > >>> >> >>>>> >>>>> is evidence of our legitimacy as a Real Thing. > However, > >>> >> >>>>> >>>>> one > >>> >> >>>>> >>>>> big > >>> >> >>>>> >>>>> missing piece is a system of governance. I don't > know > >>> >> >>>>> >>>>> exactly > >>> >> >>>>> >>>>> what > >>> >> >>>>> >>>>> this means, but I have some ideas, which I will > share > >>> >> >>>>> >>>>> below. > >>> >> >>>>> >>>>> What I > >>> >> >>>>> >>>>> want to do right now is to start a discussion > that will, > >>> >> >>>>> >>>>> hopefully, > >>> >> >>>>> >>>>> include as many people as possible on this list. > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> For me, governance means (roughly) the following: > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> - a set of procedures in writing for how various > things > >>> >> >>>>> >>>>> are to > >>> >> >>>>> >>>>> be > >>> >> >>>>> >>>>> done, such as acceptance of pull requests, > releases, > >>> >> >>>>> >>>>> designating > >>> >> >>>>> >>>>> developers as core contributors, etc. > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> - a governing body to make decisions and help > guide the > >>> >> >>>>> >>>>> project. > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> This accomplishes a number of things, which as a > project I > >>> >> >>>>> >>>>> think > >>> >> >>>>> >>>>> we > >>> >> >>>>> >>>>> need, such as: > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> - overall stability of the project. > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> - providing a system for conflict resolution. > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> - maintaining the spirit of yt as a team effort. > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> - providing a way for active contributors to get > credit > >>> >> >>>>> >>>>> for > >>> >> >>>>> >>>>> their > >>> >> >>>>> >>>>> contribution in the form of official recognition. > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> So, these are my initial thoughts, but I really > think this > >>> >> >>>>> >>>>> deserves a > >>> >> >>>>> >>>>> thorough discussion with as many people > participating as > >>> >> >>>>> >>>>> possible. > >>> >> >>>>> >>>>> Please, think about what governance means to you, > whether > >>> >> >>>>> >>>>> we > >>> >> >>>>> >>>>> need > >>> >> >>>>> >>>>> it, > >>> >> >>>>> >>>>> what it should be, and what we might get out of > it, and > >>> >> >>>>> >>>>> share > >>> >> >>>>> >>>>> your > >>> >> >>>>> >>>>> thoughts over the next few days. I look forward > to this > >>> >> >>>>> >>>>> discussion. > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> Britton > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> _______________________________________________ > >>> >> >>>>> >>>>> yt-dev mailing list > >>> >> >>>>> >>>>> yt-dev@lists.spacepope.org > >>> >> >>>>> >>>>> > >>> >> >>>>> >>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> >> >>>>> >>>> _______________________________________________ > >>> >> >>>>> >>>> yt-dev mailing list > >>> >> >>>>> >>>> yt-dev@lists.spacepope.org > >>> >> >>>>> >>>> > >>> >> >>>>> >>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> >> >>>>> >>> > >>> >> >>>>> >>> > >>> >> >>>>> >>> > >>> >> >>>>> >>> _______________________________________________ > >>> >> >>>>> >>> yt-dev mailing list > >>> >> >>>>> >>> yt-dev@lists.spacepope.org > >>> >> >>>>> >>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> >> >>>>> >> > >>> >> >>>>> >> > >>> >> >>>>> >> > >>> >> >>>>> >> -- > >>> >> >>>>> >> Michael Zingale > >>> >> >>>>> >> Associate Professor > >>> >> >>>>> >> > >>> >> >>>>> >> Dept. of Physics & Astronomy • Stony Brook > University • Stony > >>> >> >>>>> >> Brook, > >>> >> >>>>> >> NY > >>> >> >>>>> >> 11794-3800 > >>> >> >>>>> >> phone: 631-632-8225 > >>> >> >>>>> >> e-mail: Michael.Zingale@stonybrook.edu > >>> >> >>>>> >> web: http://www.astro.sunysb.edu/mzingale > >>> >> >>>>> >> > >>> >> >>>>> >> _______________________________________________ > >>> >> >>>>> >> yt-dev mailing list > >>> >> >>>>> >> yt-dev@lists.spacepope.org > >>> >> >>>>> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> >> >>>>> > _______________________________________________ > >>> >> >>>>> > yt-dev mailing list > >>> >> >>>>> > yt-dev@lists.spacepope.org > >>> >> >>>>> > > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> >> >>>>> _______________________________________________ > >>> >> >>>>> yt-dev mailing list > >>> >> >>>>> yt-dev@lists.spacepope.org > >>> >> >>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> >> >>>> > >>> >> >>>> > >>> >> >>>> > >>> >> >>>> _______________________________________________ > >>> >> >>>> yt-dev mailing list > >>> >> >>>> yt-dev@lists.spacepope.org > >>> >> >>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> >> >>>> > >>> >> >>> > >>> >> >>> > >>> >> >>> _______________________________________________ > >>> >> >>> yt-dev mailing list > >>> >> >>> yt-dev@lists.spacepope.org > >>> >> >>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> >> >>> > >>> >> >> > >>> >> > > >>> >> > > >>> >> > _______________________________________________ > >>> >> > yt-dev mailing list > >>> >> > yt-dev@lists.spacepope.org > >>> >> > > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> >> > > >>> >> _______________________________________________ > >>> >> yt-dev mailing list > >>> >> yt-dev@lists.spacepope.org > >>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > yt-dev mailing list > >>> > yt-dev@lists.spacepope.org > >>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >>> > > >>> _______________________________________________ > >>> yt-dev mailing list > >>> yt-dev@lists.spacepope.org > >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> > >> > >> > >> _______________________________________________ > >> yt-dev mailing list > >> yt-dev@lists.spacepope.org > >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> > > > > > > _______________________________________________ > > yt-dev mailing list > > yt-dev@lists.spacepope.org > > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > -- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I am in favor of Britton's bios suggestions, and share the experience that
Brian very nicely summed up about being on both sides of the process. The
bios seem like an excellent step to get the yt developers who have made
major contributions a place to list them and others to appreciate them.
I'll add that I have submitted something to A&C and found the referee
process very useful -- the referee, perhaps someone on this list?, went
through the code I was describing line-by-line with very helpful
suggestions. It seems like it could be a good place for these sort of
things.
On Mon, Sep 1, 2014 at 1:49 PM, Matthew Turk
(And I hope it goes without saying that this paper would have an enormous author list.) On Sep 1, 2014 12:49 PM, "Matthew Turk"
wrote: Discussing the paper is out of scope for this thread, but I have begun writing a yt 3 paper and was hoping to submit to the Journal of Open Research Software, which is OA, published the WSSSPE collection, and will avoid pigeon holing it as just an astro project. On Sep 1, 2014 12:43 PM, "Brian O'Shea"
wrote: I hate to be the person that responds to my own post, but I also just remembered that there are some new (and old) journals that might be worth looking at, if one wants to publish the details of individual yt modules:
Astronomy and Computing: http://www.journals.elsevier.com/astronomy-and-computing/
Computational Astrophysics and Cosmology: http://www.comp-astrophys-cosmol.com/
Computer Physics Communications: http://www.journals.elsevier.com/computer-physics-communications/
Journal of Computational Physics: http://www.journals.elsevier.com/journal-of-computational-physics/
Publications of the Astronomical Society of the Pacific: http://www.press.uchicago.edu/ucp/journals/journal/pasp.html
If there's a truly innovative/useful piece of code, it might be worth writing it up in one of those. Some are really new (A&C, CompAC), but maybe worth trying out. These two new journals in particular seem to be designed for this sort of thing - in their charters they both mention data analysis and visualization software, and A&C states that this journal "accepts regular scientific articles and review articles, but will also consider manuscripts on new software and data releases of astronomical surveys, and "reports on practice" which describe the outcomes (positive and negative) of the practical application of informatics techniques within astronomy research and operations... Providing a sustainable link to data or source code is strongly encouraged." This seems to include a lot of what we do. And, of course, for new versions of yt, one could always imagine a follow-up paper in ApJS - the original yt ApJS method paper has 135 citations, as of today!
--Brian
On Mon, Sep 1, 2014 at 1:32 PM, Brian O'Shea
wrote: I'd like to second Britton's suggestion, and elaborate on them a bit. I've been on both sides of this particular issue - applying for jobs, and also looking at peoples' CVs for postdocs and faculty positions - and it's tough to get "credit" for software in the same way that you get credit for peer-reviewed journal articles, particularly if you're developing a community code like yt (or Enzo). But, it's easier when somebody has made well-defined and significant contributions to a particular project, has documented that in various ways (i.e., in a bio, Open HUB, your CV, etc.), and in particular when that person's letter-writers have talked about it in their letters and put it in context (i.e., "Dr. X was the primary developer of yt's widely-used Foo Generator module, wrote the underlying parallel infrastructure that allows it to strongly scale to 300 quintillion cores for arbitrarily small data volumes, and has been active in improving this code and supporting its use in the yt user community for the past four years. The Foo Generator has been a key part of the analysis done in at least 14 journal articles since its first release, the majority of which would not have been written were it not for Dr. X's contribution to yt. Furthermore, Dr. X has played key roles in the development of X, Y, and Z modules for Enzo, which demonstrates Dr. X's understanding of a wide variety of numerical algorithms, particularly for large-scale parallel computing."
So, my elaboration on Britton's suggestion is really to take advantage of the bios to lay out what peoples' major contributions have been to the yt project, which is useful for lots of purposes - including giving information to potential employers, letter-writers, and people who are looking to update individual pieces of yt but don't know who they should talk to. It's not perfect, but it could help a bit.
Also, to the original point: I think that making tiers of contributors (i.e., "core" vs. "the teeming masses") is a recipe for resentment in the long term, as it becomes exclusive rather than inclusive. I can imagine a variety of conversations taking place, if only in somebody's head: "Core Developer X hasn't contributed in two years, and I've been really active for the past eighteen months - why are they still listed as a core developer and I'm not one?" or, "If the requirement is X changesets, I can game the system by making lots of very small changes and thus become a core developer." or, "If only the core developers get a say in the direction of the code, why should I even bother contributing?" And so on. Of course, it's reasonable to call yourself a core developer, and to ask letter-writers to mention that you are one, but establishing a formal set of requirements seems like it's asking for trouble.
--Brian
On Sun, Aug 31, 2014 at 9:07 AM, Britton Smith
wrote: Cameron,
I think this is a very valid issue that you raise. I have a couple concerns about creating a tier of "core" contributors on top of the member tier. I also have another idea at the end.
First, it is not clear to me the process by which we would establish the bar for a core contributor. I was comfortable with doing this rather ad-hoc for member status because it was designed to be inclusive and to establish a way that we could make decisions as a team. However, I don't think we can do that for this since it is creating a more exclusive group. If something like this is going to be created, then I think it needs to be done through the body of members that we will soon have. Otherwise, I don't know how it can be done fairly.
Second, I'm not sure that designating core contributors will be any more effective at properly crediting people for their work. At the end of the day, it will be another label that says in rather general terms that someone is very important to a project. I have been referring to myself as a core developer on job applications for a few years now and I don't think it's gotten me anything. Maybe that would change if there were an official definition of that term.
I would like to put forth another idea that could perhaps accomplish the same goal. Following the YTEP on governance, we are going to create a webpage on yt-project.org with an official definition of yt member status and a list of all members. I think it would be good if we allow those members to write bios for themselves that are linked to off of the member page. Those bios could contain anything you would want someone to know about your involvement in the project: how long you've been around, what features you've worked on, a link to your page on openhub.net, any other activities or things you've been a part of, whatever you want. That way you can not only be seen as a important person, but can get the specific credit that you deserve. Other people could even point out things that one might have missed. Maybe this will help the project seem less like a monolith and more like a lot of individual valuable pieces.
In conclusion, I am not totally opposed to core status, as long as it can be created in a fair and open way, but I would also really like to hear what people think about the bios.
Britton
On Sun, Aug 31, 2014 at 12:08 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I agree with Cameron that ultimately some way of ensuring recognition for the core developers (where len(core) < len(members)) is a good idea. Many (most?) of the big contributors to yt are in junior-level positions, and getting the recognition for their efforts will be important to getting into them more permanent positions. Unfortunately, for computational astrophysics, contributing to a software project doesn't carry as much weight as a scientific study in the eyes of the committees that do the hiring. I don't know what the right answer is, but I think Cameron's point needs to be discussed further, so that those people who are concerned/curious understand the incentive structure.
On Sat, Aug 30, 2014 at 4:18 PM, Cameron Hummels
wrote: > > > > On Sat, Aug 30, 2014 at 9:50 AM, Matthew Turk
> wrote: > >> >> >> I want to emphasize that the initial list of members Britton came up >> with (as he noted in the proposal) is only an *initial* list, and >> will >> hopefully very quickly expand to include less active "developers" >> who >> are nonetheless embedded in the community. >> >> -Matt >> >> > And this is why I think we need a list of people who are regarded as > "core" developers, to differentiate them from the what will likely be a > very large list of "members". Right now from a professional standpoint, > there is very little benefit from contributing to the code base, in that > very few people recognize your contributions (ie a handful of other > developers). Aside from a list of core developers that are highlighted on > the webpage, or having a new yt paper come out, I don't see any other way > in which this can be remedied. Perhaps others have ideas? > > >> > >> > Brian >> > >> > >> > >> > On Sat, Aug 30, 2014 at 9:30 AM, Britton Smith < >> brittonsmith@gmail.com> >> > wrote: >> >> >> >> HI Brian, >> >> >> >> I couldn't agree more on having a documentation representative >> present at >> >> team meetings. In fact, I think this was even in my original >> draft, but I >> >> somehow lost track of it. Thanks for bringing it up. I will >> get that back >> >> in there. A community representative is also a good idea, but >> I'm less sure >> >> how that role would be filled. If anyone has any thoughts on >> that, please >> >> do share. If it can't be figured out before the YTEP is >> accepted, we can >> >> definitely amend it. Thanks, Brian! >> >> >> >> Britton >> >> >> >> >> >> On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk < >> matthewturk@gmail.com> >> >> wrote: >> >>> >> >>> Hi Brian, >> >>> >> >>> On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea < >> bwoshea@gmail.com> wrote: >> >>> > Hi folks, >> >>> > >> >>> > Chiming in as somebody who is on the far periphery of yt >> development >> >>> > (having >> >>> > only contributed a couple of bug fixes/minor updates), I >> think that >> >>> > creation >> >>> > of a formal governance structure is a significant positive >> step. Given >> >>> > the >> >>> > distributed nature of the development team some level of >> coordination >> >>> > is >> >>> > critical, and I also think that having a set of >> carefully-considered >> >>> > standards about who gets a vote in terms of code direction, >> and how >> >>> > many of >> >>> > these votes are needed to enact substantial change (as >> opposed to the >> >>> > ad-hoc >> >>> > "preponderance of +1s from the mailing list" method) is an >> exceedingly >> >>> > good >> >>> > idea, as it will hopefully enhance the group's >> decision-making and make >> >>> > it >> >>> > more reflective. >> >>> > >> >>> > I also want to comment on the monthly team meetings. In >> addition to >> >>> > posting >> >>> > meeting minutes, perhaps the meeting coordinator or secretary >> could >> >>> > organize >> >>> > an agenda for the meeting and post it to the yt-dev mailing >> list a >> >>> > couple of >> >>> > days ahead of time? That way, people who are not >> participating in the >> >>> > meeting, but who may have some input on the issues at hand, >> have an >> >>> > opportunity to email suggestions. >> >>> > >> >>> > Finally, one other point: I can't help but notice that while >> the >> >>> > technical >> >>> > aspects of yt will be represented in these team meetings, >> there is no >> >>> > *explicit* representation of the yt user community or yt >> documentation. >> >>> > While in principle this isn't a problem -- Matt has made the >> point many >> >>> > times that the difference between user and developer isn't >> necessarily >> >>> > meaningful in our context -- I do think that having somebody >> involved >> >>> > whose >> >>> > explicit responsibility is to consider the questions "how >> will this >> >>> > impact >> >>> > the broader yt user community?" and "what's missing from the >> >>> > documentation >> >>> > that could be added or improved?" may be beneficial. >> >>> >> >>> Yes, I agree. I actually have a few people I would submit as >> >>> nominations for this role, but it seems to me it's certainly >> one that >> >>> should be represented. >> >>> >> >>> > >> >>> > Anyway, small nit-picks aside, I think this is a great idea. >> Thanks to >> >>> > Britton for starting the ball rolling! >> >>> > >> >>> > --Brian >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk < >> matthewturk@gmail.com> >> >>> > wrote: >> >>> >> >> >>> >> Hi Britton, >> >>> >> >> >>> >> I think this is really, really important, and I'm really >> happy with >> >>> >> the YTEP as it stands. >> >>> >> >> >>> >> We've only gotten feedback from a few people. I think it's >> really >> >>> >> important to get both positive and negative feedback from >> people on >> >>> >> this -- even to the level of "geez, stop taking yourselves so >> >>> >> seriously!" :) Do you think maybe an email to the yt-users >> mailing >> >>> >> list would be productive? Or even directly writing to the >> people >> >>> >> identified as "founding" members? >> >>> >> >> >>> >> -Matt >> >>> >> >> >>> >> On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith >> >>> >> >> >>> >> wrote: >> >>> >> > Hi everyone, >> >>> >> > >> >>> >> > I have just issued a pull request to the YTEP repository >> containing >> >>> >> > an >> >>> >> > initial draft of yt team guidelines. I encourage everyone >> to take a >> >>> >> > look at >> >>> >> > it and offer their feedback. In case you don't get the >> >>> >> > notification, >> >>> >> > the PR >> >>> >> > can be viewed here: >> >>> >> > >> >>> >> > >> >>> >> > >> https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras... >> >>> >> > >> >>> >> > Britton >> >>> >> > >> >>> >> > >> >>> >> > On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith >> >>> >> > >> >>> >> > wrote: >> >>> >> >> >> >>> >> >> Hi Sam, >> >>> >> >> >> >>> >> >> This is an excellent point. I think it's important not to >> >>> >> >> overburden a >> >>> >> >> single person by being forever responsible for a large >> chunk of the >> >>> >> >> code. I >> >>> >> >> also think it's good to give as many as are willing an >> opportunity >> >>> >> >> to >> >>> >> >> share >> >>> >> >> the role. Perhaps there is a team of people or >> subcommittee that >> >>> >> >> is >> >>> >> >> responsible for figuring out who their representative >> is. This can >> >>> >> >> be >> >>> >> >> ironed out. >> >>> >> >> >> >>> >> >> I think we've gotten enough positive response to start >> thinking >> >>> >> >> about a >> >>> >> >> YTEP that lays it all out. I will start something this >> week, ask >> >>> >> >> for >> >>> >> >> feedback, and we can all develop this together. >> >>> >> >> >> >>> >> >> In the mean time, if you would still like to chime in on >> this >> >>> >> >> discussion, >> >>> >> >> please do so. >> >>> >> >> Thanks, everyone. >> >>> >> >> >> >>> >> >> Britton >> >>> >> >> >> >>> >> >> >> >>> >> >> On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman >> >>> >> >> >> >>> >> >> wrote: >> >>> >> >>> >> >>> >> >>> Hi all, >> >>> >> >>> >> >>> >> >>> Britton -- I really like these ideas, and I like the >> member level >> >>> >> >>> being >> >>> >> >>> defined as write access. >> >>> >> >>> >> >>> >> >>> I'm a bit more concerned about the officers designation >> in terms >> >>> >> >>> of >> >>> >> >>> the >> >>> >> >>> logistics of matching people with sections of the code. >> I could >> >>> >> >>> see >> >>> >> >>> something working where on a 6-month basis, each of the >> main areas >> >>> >> >>> in >> >>> >> >>> yt are >> >>> >> >>> assigned a lead. That lead isn't necessarily the person >> who has >> >>> >> >>> written the >> >>> >> >>> most in the area, but rather a person who is willing to >> keep track >> >>> >> >>> of >> >>> >> >>> that >> >>> >> >>> area of the codebase for the next 6 months, so that when >> it comes >> >>> >> >>> to >> >>> >> >>> doing >> >>> >> >>> releases, they are the ones that know what has changed >> and where >> >>> >> >>> things are >> >>> >> >>> not working well. Maybe that's too much of a process, >> but I also >> >>> >> >>> think we >> >>> >> >>> should be wary of assigning potentially long-lasting >> labels to >> >>> >> >>> either >> >>> >> >>> people >> >>> >> >>> or code. Semi-regular meetings for this set of people >> would be >> >>> >> >>> great. >> >>> >> >>> >> >>> >> >>> Anyways, I'm definitely a +1 on a YTEP for all of this, >> and look >> >>> >> >>> forward >> >>> >> >>> to hearing more! >> >>> >> >>> >> >>> >> >>> Cheers, >> >>> >> >>> Sam >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller >> >>> >> >>> >> >>> >> >>> wrote: >> >>> >> >>>> >> >>> >> >>>> +1, absolutely. Right now, yt has a really high bus >> factor. I >> >>> >> >>>> think >> >>> >> >>>> this would help that a lot. >> >>> >> >>>> >> >>> >> >>>> >> >>> >> >>>> On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone >> >>> >> >>>> >> >>> >> >>>> wrote: >> >>> >> >>>>> >> >>> >> >>>>> +1 as well on all suggestions >> >>> >> >>>>> >> >>> >> >>>>> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki < >> karraki@nmsu.edu> >> >>> >> >>>>> > wrote: >> >>> >> >>>>> > >> >>> >> >>>>> > I wanted to put my strong +1 out there even though I >> don't >> >>> >> >>>>> > respond >> >>> >> >>>>> > often to dev emails. This sounds like a great >> direction for >> >>> >> >>>>> > yt! >> >>> >> >>>>> > >> >>> >> >>>>> > -Kenza >> >>> >> >>>>> > >> >>> >> >>>>> > --- >> >>> >> >>>>> > Kenza Arraki >> >>> >> >>>>> > PhD candidate >> >>> >> >>>>> > New Mexico State University >> >>> >> >>>>> > Department of Astronomy >> >>> >> >>>>> > >> >>> >> >>>>> > >> >>> >> >>>>> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale >> >>> >> >>>>> > wrote: >> >>> >> >>>>> >> these all sound like good ideas to me. Some simply >> operating >> >>> >> >>>>> >> procedures, >> >>> >> >>>>> >> like "don't merge your own pull requests" might be >> good too. >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith >> >>> >> >>>>> >> >> >>> >> >>>>> >> wrote: >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> I'm very in favor of putting some official >> procedures into a >> >>> >> >>>>> >>> YTEP. >> >>> >> >>>>> >>> Having >> >>> >> >>>>> >>> a codified process may also help with conflict >> resolution as >> >>> >> >>>>> >>> well. >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> Apache does something with their projects where >> developers >> >>> >> >>>>> >>> who >> >>> >> >>>>> >>> make >> >>> >> >>>>> >>> sustained contribution are made "members" after >> nomination >> >>> >> >>>>> >>> by >> >>> >> >>>>> >>> another member >> >>> >> >>>>> >>> and are given write access to the main repo. It's >> a small >> >>> >> >>>>> >>> thing, >> >>> >> >>>>> >>> but if we >> >>> >> >>>>> >>> perhaps have an official definition of "yt member" >> in a YTEP >> >>> >> >>>>> >>> with a >> >>> >> >>>>> >>> posted >> >>> >> >>>>> >>> list of members, it can be something people can >> point to as >> >>> >> >>>>> >>> a >> >>> >> >>>>> >>> way >> >>> >> >>>>> >>> of >> >>> >> >>>>> >>> demonstrating that they've done significant work >> on the >> >>> >> >>>>> >>> project. >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> I think it might also be good to have officer-like >> positions >> >>> >> >>>>> >>> where >> >>> >> >>>>> >>> people >> >>> >> >>>>> >>> are representatives for various areas of the code, >> such as >> >>> >> >>>>> >>> data >> >>> >> >>>>> >>> structures, >> >>> >> >>>>> >>> visualization, analysis_modules, etc. and to have >> >>> >> >>>>> >>> semi-regular >> >>> >> >>>>> >>> meeting of >> >>> >> >>>>> >>> these people. This may be as much leadership as >> we need for >> >>> >> >>>>> >>> now, >> >>> >> >>>>> >>> just a >> >>> >> >>>>> >>> group that meets on a schedule to make sure >> everyone's on >> >>> >> >>>>> >>> the >> >>> >> >>>>> >>> same >> >>> >> >>>>> >>> page with >> >>> >> >>>>> >>> releases and major development efforts. >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> What do people think of something like this? >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> wrote: >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> Hi Britton, >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> Thanks for bringing this up -- it's a tough >> topic, but also >> >>> >> >>>>> >>>> I >> >>> >> >>>>> >>>> think >> >>> >> >>>>> >>>> really important. At the WSSSPE conference last >> year, a >> >>> >> >>>>> >>>> paper >> >>> >> >>>>> >>>> was >> >>> >> >>>>> >>>> submitted talking about the Apache model: >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> >> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> which talks about a lot of related topics. >> Apache does >> >>> >> >>>>> >>>> some >> >>> >> >>>>> >>>> interesting things. They use the word >> "meritocracy" which >> >>> >> >>>>> >>>> I am >> >>> >> >>>>> >>>> rather >> >>> >> >>>>> >>>> -1 on using (see, for instance, >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> >> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... >> >>> >> >>>>> >>>> ) but I do think there is something to be said >> for a large >> >>> >> >>>>> >>>> part >> >>> >> >>>>> >>>> of >> >>> >> >>>>> >>>> their methods of organization. >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> Like you, I think we are overdue. I would like >> to point >> >>> >> >>>>> >>>> out >> >>> >> >>>>> >>>> that, >> >>> >> >>>>> >>>> for >> >>> >> >>>>> >>>> all intents and purposes, you are *already* the >> ombudsman >> >>> >> >>>>> >>>> for >> >>> >> >>>>> >>>> the >> >>> >> >>>>> >>>> yt >> >>> >> >>>>> >>>> community. I don't think you're proposing we >> have a >> >>> >> >>>>> >>>> committee >> >>> >> >>>>> >>>> that >> >>> >> >>>>> >>>> bosses everyone around, but rather one that >> enables a >> >>> >> >>>>> >>>> larger >> >>> >> >>>>> >>>> number of >> >>> >> >>>>> >>>> people to have a say, particularly because yt has >> become >> >>> >> >>>>> >>>> embedded >> >>> >> >>>>> >>>> in >> >>> >> >>>>> >>>> many of our scientific workflows and it touches a >> lot of >> >>> >> >>>>> >>>> research >> >>> >> >>>>> >>>> activities now. I like the idea of members. I >> like the >> >>> >> >>>>> >>>> idea >> >>> >> >>>>> >>>> of a >> >>> >> >>>>> >>>> project management committee, but it's not clear >> to me how >> >>> >> >>>>> >>>> that >> >>> >> >>>>> >>>> would >> >>> >> >>>>> >>>> work, or which decisions we have made recently >> that they >> >>> >> >>>>> >>>> would >> >>> >> >>>>> >>>> weigh >> >>> >> >>>>> >>>> in on. I also really like the idea of having >> "code >> >>> >> >>>>> >>>> liasons" to >> >>> >> >>>>> >>>> different data platforms and/or communities, and >> the idea >> >>> >> >>>>> >>>> of >> >>> >> >>>>> >>>> having >> >>> >> >>>>> >>>> people who are responsible for many different >> areas of the >> >>> >> >>>>> >>>> code >> >>> >> >>>>> >>>> and >> >>> >> >>>>> >>>> codifying that in some way is quite attractive to >> me. >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> For what it's worth, a few weeks ago I gave a >> presentation >> >>> >> >>>>> >>>> on >> >>> >> >>>>> >>>> my >> >>> >> >>>>> >>>> "vision" for the future of yt ( >> http://goo.gl/JKt6MA). The >> >>> >> >>>>> >>>> thing >> >>> >> >>>>> >>>> is, >> >>> >> >>>>> >>>> while I gave this presentation, it's just *my* >> vision -- it >> >>> >> >>>>> >>>> is >> >>> >> >>>>> >>>> not >> >>> >> >>>>> >>>> necessarily anyone else's vision. And I think >> it's time we >> >>> >> >>>>> >>>> have >> >>> >> >>>>> >>>> some >> >>> >> >>>>> >>>> method of taking into account a diverse set of >> opinions for >> >>> >> >>>>> >>>> what >> >>> >> >>>>> >>>> we as >> >>> >> >>>>> >>>> a community can emphasize, how we resolve >> conflicts, and so >> >>> >> >>>>> >>>> on >> >>> >> >>>>> >>>> and >> >>> >> >>>>> >>>> so >> >>> >> >>>>> >>>> forth. >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> Again, thanks for bringing this up. We need to >> have this >> >>> >> >>>>> >>>> conversation. >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> -Matt >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> wrote: >> >>> >> >>>>> >>>>> Greeting yt developers, >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> First, I want to congratulate everyone here on >> the >> >>> >> >>>>> >>>>> successful >> >>> >> >>>>> >>>>> release >> >>> >> >>>>> >>>>> of yt-3.0. This was a massive effort on the >> part of so >> >>> >> >>>>> >>>>> many >> >>> >> >>>>> >>>>> and >> >>> >> >>>>> >>>>> a >> >>> >> >>>>> >>>>> true testament to the strength of this team. >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> At the time of writing this, there are 78 >> members of the >> >>> >> >>>>> >>>>> yt-dev >> >>> >> >>>>> >>>>> mailing list. As someone who does most of their >> work in >> >>> >> >>>>> >>>>> very >> >>> >> >>>>> >>>>> small >> >>> >> >>>>> >>>>> collaborations, this amazes me and make me very >> proud. In >> >>> >> >>>>> >>>>> case >> >>> >> >>>>> >>>>> you're >> >>> >> >>>>> >>>>> wondering, the yt-users list has 268 members. >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> As a project, yt has a significant amount of >> >>> >> >>>>> >>>>> infrastructure: >> >>> >> >>>>> >>>>> code >> >>> >> >>>>> >>>>> review with pull requests, issue tracking, >> automated >> >>> >> >>>>> >>>>> testing, >> >>> >> >>>>> >>>>> emails >> >>> >> >>>>> >>>>> lists, an IRC channel, enhancement proposals, >> workshops. >> >>> >> >>>>> >>>>> All >> >>> >> >>>>> >>>>> of >> >>> >> >>>>> >>>>> this >> >>> >> >>>>> >>>>> is evidence of our legitimacy as a Real Thing. >> However, >> >>> >> >>>>> >>>>> one >> >>> >> >>>>> >>>>> big >> >>> >> >>>>> >>>>> missing piece is a system of governance. I >> don't know >> >>> >> >>>>> >>>>> exactly >> >>> >> >>>>> >>>>> what >> >>> >> >>>>> >>>>> this means, but I have some ideas, which I will >> share >> >>> >> >>>>> >>>>> below. >> >>> >> >>>>> >>>>> What I >> >>> >> >>>>> >>>>> want to do right now is to start a discussion >> that will, >> >>> >> >>>>> >>>>> hopefully, >> >>> >> >>>>> >>>>> include as many people as possible on this list. >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> For me, governance means (roughly) the following: >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> - a set of procedures in writing for how various >> things >> >>> >> >>>>> >>>>> are to >> >>> >> >>>>> >>>>> be >> >>> >> >>>>> >>>>> done, such as acceptance of pull requests, >> releases, >> >>> >> >>>>> >>>>> designating >> >>> >> >>>>> >>>>> developers as core contributors, etc. >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> - a governing body to make decisions and help >> guide the >> >>> >> >>>>> >>>>> project. >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> This accomplishes a number of things, which as a >> project I >> >>> >> >>>>> >>>>> think >> >>> >> >>>>> >>>>> we >> >>> >> >>>>> >>>>> need, such as: >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> - overall stability of the project. >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> - providing a system for conflict resolution. >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> - maintaining the spirit of yt as a team effort. >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> - providing a way for active contributors to get >> credit >> >>> >> >>>>> >>>>> for >> >>> >> >>>>> >>>>> their >> >>> >> >>>>> >>>>> contribution in the form of official >> recognition. >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> So, these are my initial thoughts, but I really >> think this >> >>> >> >>>>> >>>>> deserves a >> >>> >> >>>>> >>>>> thorough discussion with as many people >> participating as >> >>> >> >>>>> >>>>> possible. >> >>> >> >>>>> >>>>> Please, think about what governance means to >> you, whether >> >>> >> >>>>> >>>>> we >> >>> >> >>>>> >>>>> need >> >>> >> >>>>> >>>>> it, >> >>> >> >>>>> >>>>> what it should be, and what we might get out of >> it, and >> >>> >> >>>>> >>>>> share >> >>> >> >>>>> >>>>> your >> >>> >> >>>>> >>>>> thoughts over the next few days. I look forward >> to this >> >>> >> >>>>> >>>>> discussion. >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> Britton >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> _______________________________________________ >> >>> >> >>>>> >>>>> yt-dev mailing list >> >>> >> >>>>> >>>>> yt-dev@lists.spacepope.org >> >>> >> >>>>> >>>>> >> >>> >> >>>>> >>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> >> >>>>> >>>> _______________________________________________ >> >>> >> >>>>> >>>> yt-dev mailing list >> >>> >> >>>>> >>>> yt-dev@lists.spacepope.org >> >>> >> >>>>> >>>> >> >>> >> >>>>> >>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> >> >>> >> >>>>> >>> _______________________________________________ >> >>> >> >>>>> >>> yt-dev mailing list >> >>> >> >>>>> >>> yt-dev@lists.spacepope.org >> >>> >> >>>>> >>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> >> >>> >> >>>>> >> -- >> >>> >> >>>>> >> Michael Zingale >> >>> >> >>>>> >> Associate Professor >> >>> >> >>>>> >> >> >>> >> >>>>> >> Dept. of Physics & Astronomy • Stony Brook >> University • Stony >> >>> >> >>>>> >> Brook, >> >>> >> >>>>> >> NY >> >>> >> >>>>> >> 11794-3800 >> >>> >> >>>>> >> phone: 631-632-8225 >> >>> >> >>>>> >> e-mail: Michael.Zingale@stonybrook.edu >> >>> >> >>>>> >> web: http://www.astro.sunysb.edu/mzingale >> >>> >> >>>>> >> >> >>> >> >>>>> >> _______________________________________________ >> >>> >> >>>>> >> yt-dev mailing list >> >>> >> >>>>> >> yt-dev@lists.spacepope.org >> >>> >> >>>>> >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> >> >>>>> > _______________________________________________ >> >>> >> >>>>> > yt-dev mailing list >> >>> >> >>>>> > yt-dev@lists.spacepope.org >> >>> >> >>>>> > >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> >> >>>>> _______________________________________________ >> >>> >> >>>>> yt-dev mailing list >> >>> >> >>>>> yt-dev@lists.spacepope.org >> >>> >> >>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> >> >>>> >> >>> >> >>>> >> >>> >> >>>> >> >>> >> >>>> _______________________________________________ >> >>> >> >>>> yt-dev mailing list >> >>> >> >>>> yt-dev@lists.spacepope.org >> >>> >> >>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> >> >>>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> >> >>> yt-dev mailing list >> >>> >> >>> yt-dev@lists.spacepope.org >> >>> >> >>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> >> >>> >> >>> >> >> >> >>> >> > >> >>> >> > >> >>> >> > _______________________________________________ >> >>> >> > yt-dev mailing list >> >>> >> > yt-dev@lists.spacepope.org >> >>> >> > >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> >> > >> >>> >> _______________________________________________ >> >>> >> yt-dev mailing list >> >>> >> yt-dev@lists.spacepope.org >> >>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> > >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > yt-dev mailing list >> >>> > yt-dev@lists.spacepope.org >> >>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >>> > >> >>> _______________________________________________ >> >>> yt-dev mailing list >> >>> yt-dev@lists.spacepope.org >> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >> >> >> >> >> >> _______________________________________________ >> >> yt-dev mailing list >> >> yt-dev@lists.spacepope.org >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> >> > >> > >> > _______________________________________________ >> > yt-dev mailing list >> > yt-dev@lists.spacepope.org >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > > > > -- > Cameron Hummels > Postdoctoral Researcher > Steward Observatory > University of Arizona > http://chummels.org > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > -- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
Hi Britton,
I created a pull request that adds a members page, with spots for bios.
https://bitbucket.org/yt_analysis/website/pull-request/52/adding-initial-mem...
-Matt
On Sun, Aug 31, 2014 at 8:07 AM, Britton Smith
Cameron,
I think this is a very valid issue that you raise. I have a couple concerns about creating a tier of "core" contributors on top of the member tier. I also have another idea at the end.
First, it is not clear to me the process by which we would establish the bar for a core contributor. I was comfortable with doing this rather ad-hoc for member status because it was designed to be inclusive and to establish a way that we could make decisions as a team. However, I don't think we can do that for this since it is creating a more exclusive group. If something like this is going to be created, then I think it needs to be done through the body of members that we will soon have. Otherwise, I don't know how it can be done fairly.
Second, I'm not sure that designating core contributors will be any more effective at properly crediting people for their work. At the end of the day, it will be another label that says in rather general terms that someone is very important to a project. I have been referring to myself as a core developer on job applications for a few years now and I don't think it's gotten me anything. Maybe that would change if there were an official definition of that term.
I would like to put forth another idea that could perhaps accomplish the same goal. Following the YTEP on governance, we are going to create a webpage on yt-project.org with an official definition of yt member status and a list of all members. I think it would be good if we allow those members to write bios for themselves that are linked to off of the member page. Those bios could contain anything you would want someone to know about your involvement in the project: how long you've been around, what features you've worked on, a link to your page on openhub.net, any other activities or things you've been a part of, whatever you want. That way you can not only be seen as a important person, but can get the specific credit that you deserve. Other people could even point out things that one might have missed. Maybe this will help the project seem less like a monolith and more like a lot of individual valuable pieces.
In conclusion, I am not totally opposed to core status, as long as it can be created in a fair and open way, but I would also really like to hear what people think about the bios.
Britton
On Sun, Aug 31, 2014 at 12:08 AM, Michael Zingale
wrote: I agree with Cameron that ultimately some way of ensuring recognition for the core developers (where len(core) < len(members)) is a good idea. Many (most?) of the big contributors to yt are in junior-level positions, and getting the recognition for their efforts will be important to getting into them more permanent positions. Unfortunately, for computational astrophysics, contributing to a software project doesn't carry as much weight as a scientific study in the eyes of the committees that do the hiring. I don't know what the right answer is, but I think Cameron's point needs to be discussed further, so that those people who are concerned/curious understand the incentive structure.
On Sat, Aug 30, 2014 at 4:18 PM, Cameron Hummels
wrote: On Sat, Aug 30, 2014 at 9:50 AM, Matthew Turk
wrote: I want to emphasize that the initial list of members Britton came up with (as he noted in the proposal) is only an *initial* list, and will hopefully very quickly expand to include less active "developers" who are nonetheless embedded in the community.
-Matt
And this is why I think we need a list of people who are regarded as "core" developers, to differentiate them from the what will likely be a very large list of "members". Right now from a professional standpoint, there is very little benefit from contributing to the code base, in that very few people recognize your contributions (ie a handful of other developers). Aside from a list of core developers that are highlighted on the webpage, or having a new yt paper come out, I don't see any other way in which this can be remedied. Perhaps others have ideas?
Brian
On Sat, Aug 30, 2014 at 9:30 AM, Britton Smith
wrote: HI Brian,
I couldn't agree more on having a documentation representative present at team meetings. In fact, I think this was even in my original draft, but I somehow lost track of it. Thanks for bringing it up. I will get that back in there. A community representative is also a good idea, but I'm less sure how that role would be filled. If anyone has any thoughts on that, please do share. If it can't be figured out before the YTEP is accepted, we can definitely amend it. Thanks, Brian!
Britton
On Fri, Aug 29, 2014 at 10:16 PM, Matthew Turk
wrote: > > Hi Brian, > > On Fri, Aug 29, 2014 at 3:32 PM, Brian O'Shea > wrote: > > Hi folks, > > > > Chiming in as somebody who is on the far periphery of yt > > development > > (having > > only contributed a couple of bug fixes/minor updates), I think > > that > > creation > > of a formal governance structure is a significant positive step. > > Given > > the > > distributed nature of the development team some level of > > coordination > > is > > critical, and I also think that having a set of > > carefully-considered > > standards about who gets a vote in terms of code direction, and > > how > > many of > > these votes are needed to enact substantial change (as opposed to > > the > > ad-hoc > > "preponderance of +1s from the mailing list" method) is an > > exceedingly > > good > > idea, as it will hopefully enhance the group's decision-making and > > make > > it > > more reflective. > > > > I also want to comment on the monthly team meetings. In addition > > to > > posting > > meeting minutes, perhaps the meeting coordinator or secretary > > could > > organize > > an agenda for the meeting and post it to the yt-dev mailing list a > > couple of > > days ahead of time? That way, people who are not participating in > > the > > meeting, but who may have some input on the issues at hand, have > > an > > opportunity to email suggestions. > > > > Finally, one other point: I can't help but notice that while the > > technical > > aspects of yt will be represented in these team meetings, there is > > no > > *explicit* representation of the yt user community or yt > > documentation. > > While in principle this isn't a problem -- Matt has made the point > > many > > times that the difference between user and developer isn't > > necessarily > > meaningful in our context -- I do think that having somebody > > involved > > whose > > explicit responsibility is to consider the questions "how will > > this > > impact > > the broader yt user community?" and "what's missing from the > > documentation > > that could be added or improved?" may be beneficial. > > Yes, I agree. I actually have a few people I would submit as > nominations for this role, but it seems to me it's certainly one > that > should be represented. > > > > > Anyway, small nit-picks aside, I think this is a great idea. > > Thanks to > > Britton for starting the ball rolling! > > > > --Brian > > > > > > > > > > On Tue, Aug 26, 2014 at 4:20 PM, Matthew Turk > > > > wrote: > >> > >> Hi Britton, > >> > >> I think this is really, really important, and I'm really happy > >> with > >> the YTEP as it stands. > >> > >> We've only gotten feedback from a few people. I think it's > >> really > >> important to get both positive and negative feedback from people > >> on > >> this -- even to the level of "geez, stop taking yourselves so > >> seriously!" :) Do you think maybe an email to the yt-users > >> mailing > >> list would be productive? Or even directly writing to the people > >> identified as "founding" members? > >> > >> -Matt > >> > >> On Mon, Aug 25, 2014 at 4:50 PM, Britton Smith > >> > >> wrote: > >> > Hi everyone, > >> > > >> > I have just issued a pull request to the YTEP repository > >> > containing > >> > an > >> > initial draft of yt team guidelines. I encourage everyone to > >> > take a > >> > look at > >> > it and offer their feedback. In case you don't get the > >> > notification, > >> > the PR > >> > can be viewed here: > >> > > >> > > >> > > >> > https://bitbucket.org/yt_analysis/ytep/pull-request/40/ytep-1776-team-infras... > >> > > >> > Britton > >> > > >> > > >> > On Mon, Aug 18, 2014 at 12:24 PM, Britton Smith > >> > > >> > wrote: > >> >> > >> >> Hi Sam, > >> >> > >> >> This is an excellent point. I think it's important not to > >> >> overburden a > >> >> single person by being forever responsible for a large chunk > >> >> of the > >> >> code. I > >> >> also think it's good to give as many as are willing an > >> >> opportunity > >> >> to > >> >> share > >> >> the role. Perhaps there is a team of people or subcommittee > >> >> that > >> >> is > >> >> responsible for figuring out who their representative is. > >> >> This can > >> >> be > >> >> ironed out. > >> >> > >> >> I think we've gotten enough positive response to start > >> >> thinking > >> >> about a > >> >> YTEP that lays it all out. I will start something this week, > >> >> ask > >> >> for > >> >> feedback, and we can all develop this together. > >> >> > >> >> In the mean time, if you would still like to chime in on this > >> >> discussion, > >> >> please do so. > >> >> Thanks, everyone. > >> >> > >> >> Britton > >> >> > >> >> > >> >> On Sun, Aug 17, 2014 at 4:20 PM, Sam Skillman > >> >> > >> >> wrote: > >> >>> > >> >>> Hi all, > >> >>> > >> >>> Britton -- I really like these ideas, and I like the member > >> >>> level > >> >>> being > >> >>> defined as write access. > >> >>> > >> >>> I'm a bit more concerned about the officers designation in > >> >>> terms > >> >>> of > >> >>> the > >> >>> logistics of matching people with sections of the code. I > >> >>> could > >> >>> see > >> >>> something working where on a 6-month basis, each of the main > >> >>> areas > >> >>> in > >> >>> yt are > >> >>> assigned a lead. That lead isn't necessarily the person who > >> >>> has > >> >>> written the > >> >>> most in the area, but rather a person who is willing to keep > >> >>> track > >> >>> of > >> >>> that > >> >>> area of the codebase for the next 6 months, so that when it > >> >>> comes > >> >>> to > >> >>> doing > >> >>> releases, they are the ones that know what has changed and > >> >>> where > >> >>> things are > >> >>> not working well. Maybe that's too much of a process, but I > >> >>> also > >> >>> think we > >> >>> should be wary of assigning potentially long-lasting labels > >> >>> to > >> >>> either > >> >>> people > >> >>> or code. Semi-regular meetings for this set of people would > >> >>> be > >> >>> great. > >> >>> > >> >>> Anyways, I'm definitely a +1 on a YTEP for all of this, and > >> >>> look > >> >>> forward > >> >>> to hearing more! > >> >>> > >> >>> Cheers, > >> >>> Sam > >> >>> > >> >>> > >> >>> On Sat, Aug 16, 2014 at 7:08 PM, B.W. Keller > >> >>> > >> >>> wrote: > >> >>>> > >> >>>> +1, absolutely. Right now, yt has a really high bus factor. > >> >>>> I > >> >>>> think > >> >>>> this would help that a lot. > >> >>>> > >> >>>> > >> >>>> On Fri, Aug 15, 2014 at 7:40 PM, Chris Malone > >> >>>> > >> >>>> wrote: > >> >>>>> > >> >>>>> +1 as well on all suggestions > >> >>>>> > >> >>>>> > On Aug 15, 2014, at 5:32 PM, Kenza Arraki > >> >>>>> > > >> >>>>> > wrote: > >> >>>>> > > >> >>>>> > I wanted to put my strong +1 out there even though I > >> >>>>> > don't > >> >>>>> > respond > >> >>>>> > often to dev emails. This sounds like a great direction > >> >>>>> > for > >> >>>>> > yt! > >> >>>>> > > >> >>>>> > -Kenza > >> >>>>> > > >> >>>>> > --- > >> >>>>> > Kenza Arraki > >> >>>>> > PhD candidate > >> >>>>> > New Mexico State University > >> >>>>> > Department of Astronomy > >> >>>>> > > >> >>>>> > > >> >>>>> > On Fri, Aug 15, 2014 at 4:06 PM, Michael Zingale > >> >>>>> > wrote: > >> >>>>> >> these all sound like good ideas to me. Some simply > >> >>>>> >> operating > >> >>>>> >> procedures, > >> >>>>> >> like "don't merge your own pull requests" might be good > >> >>>>> >> too. > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> On Fri, Aug 15, 2014 at 3:50 PM, Britton Smith > >> >>>>> >> > >> >>>>> >> wrote: > >> >>>>> >>> > >> >>>>> >>> I'm very in favor of putting some official procedures > >> >>>>> >>> into a > >> >>>>> >>> YTEP. > >> >>>>> >>> Having > >> >>>>> >>> a codified process may also help with conflict > >> >>>>> >>> resolution as > >> >>>>> >>> well. > >> >>>>> >>> > >> >>>>> >>> Apache does something with their projects where > >> >>>>> >>> developers > >> >>>>> >>> who > >> >>>>> >>> make > >> >>>>> >>> sustained contribution are made "members" after > >> >>>>> >>> nomination > >> >>>>> >>> by > >> >>>>> >>> another member > >> >>>>> >>> and are given write access to the main repo. It's a > >> >>>>> >>> small > >> >>>>> >>> thing, > >> >>>>> >>> but if we > >> >>>>> >>> perhaps have an official definition of "yt member" in a > >> >>>>> >>> YTEP > >> >>>>> >>> with a > >> >>>>> >>> posted > >> >>>>> >>> list of members, it can be something people can point > >> >>>>> >>> to as > >> >>>>> >>> a > >> >>>>> >>> way > >> >>>>> >>> of > >> >>>>> >>> demonstrating that they've done significant work on the > >> >>>>> >>> project. > >> >>>>> >>> > >> >>>>> >>> I think it might also be good to have officer-like > >> >>>>> >>> positions > >> >>>>> >>> where > >> >>>>> >>> people > >> >>>>> >>> are representatives for various areas of the code, such > >> >>>>> >>> as > >> >>>>> >>> data > >> >>>>> >>> structures, > >> >>>>> >>> visualization, analysis_modules, etc. and to have > >> >>>>> >>> semi-regular > >> >>>>> >>> meeting of > >> >>>>> >>> these people. This may be as much leadership as we > >> >>>>> >>> need for > >> >>>>> >>> now, > >> >>>>> >>> just a > >> >>>>> >>> group that meets on a schedule to make sure everyone's > >> >>>>> >>> on > >> >>>>> >>> the > >> >>>>> >>> same > >> >>>>> >>> page with > >> >>>>> >>> releases and major development efforts. > >> >>>>> >>> > >> >>>>> >>> What do people think of something like this? > >> >>>>> >>> > >> >>>>> >>> On Wed, Aug 13, 2014 at 4:58 PM, Matthew Turk > >> >>>>> >>> > >> >>>>> >>> wrote: > >> >>>>> >>>> > >> >>>>> >>>> Hi Britton, > >> >>>>> >>>> > >> >>>>> >>>> Thanks for bringing this up -- it's a tough topic, but > >> >>>>> >>>> also > >> >>>>> >>>> I > >> >>>>> >>>> think > >> >>>>> >>>> really important. At the WSSSPE conference last year, > >> >>>>> >>>> a > >> >>>>> >>>> paper > >> >>>>> >>>> was > >> >>>>> >>>> submitted talking about the Apache model: > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> http://figshare.com/articles/Sustainable_Cyberinfrastructure_Software_Throug... > >> >>>>> >>>> > >> >>>>> >>>> which talks about a lot of related topics. Apache > >> >>>>> >>>> does > >> >>>>> >>>> some > >> >>>>> >>>> interesting things. They use the word "meritocracy" > >> >>>>> >>>> which > >> >>>>> >>>> I am > >> >>>>> >>>> rather > >> >>>>> >>>> -1 on using (see, for instance, > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-commun... > >> >>>>> >>>> ) but I do think there is something to be said for a > >> >>>>> >>>> large > >> >>>>> >>>> part > >> >>>>> >>>> of > >> >>>>> >>>> their methods of organization. > >> >>>>> >>>> > >> >>>>> >>>> Like you, I think we are overdue. I would like to > >> >>>>> >>>> point > >> >>>>> >>>> out > >> >>>>> >>>> that, > >> >>>>> >>>> for > >> >>>>> >>>> all intents and purposes, you are *already* the > >> >>>>> >>>> ombudsman > >> >>>>> >>>> for > >> >>>>> >>>> the > >> >>>>> >>>> yt > >> >>>>> >>>> community. I don't think you're proposing we have a > >> >>>>> >>>> committee > >> >>>>> >>>> that > >> >>>>> >>>> bosses everyone around, but rather one that enables a > >> >>>>> >>>> larger > >> >>>>> >>>> number of > >> >>>>> >>>> people to have a say, particularly because yt has > >> >>>>> >>>> become > >> >>>>> >>>> embedded > >> >>>>> >>>> in > >> >>>>> >>>> many of our scientific workflows and it touches a lot > >> >>>>> >>>> of > >> >>>>> >>>> research > >> >>>>> >>>> activities now. I like the idea of members. I like > >> >>>>> >>>> the > >> >>>>> >>>> idea > >> >>>>> >>>> of a > >> >>>>> >>>> project management committee, but it's not clear to me > >> >>>>> >>>> how > >> >>>>> >>>> that > >> >>>>> >>>> would > >> >>>>> >>>> work, or which decisions we have made recently that > >> >>>>> >>>> they > >> >>>>> >>>> would > >> >>>>> >>>> weigh > >> >>>>> >>>> in on. I also really like the idea of having "code > >> >>>>> >>>> liasons" to > >> >>>>> >>>> different data platforms and/or communities, and the > >> >>>>> >>>> idea > >> >>>>> >>>> of > >> >>>>> >>>> having > >> >>>>> >>>> people who are responsible for many different areas of > >> >>>>> >>>> the > >> >>>>> >>>> code > >> >>>>> >>>> and > >> >>>>> >>>> codifying that in some way is quite attractive to me. > >> >>>>> >>>> > >> >>>>> >>>> For what it's worth, a few weeks ago I gave a > >> >>>>> >>>> presentation > >> >>>>> >>>> on > >> >>>>> >>>> my > >> >>>>> >>>> "vision" for the future of yt (http://goo.gl/JKt6MA). > >> >>>>> >>>> The > >> >>>>> >>>> thing > >> >>>>> >>>> is, > >> >>>>> >>>> while I gave this presentation, it's just *my* vision > >> >>>>> >>>> -- it > >> >>>>> >>>> is > >> >>>>> >>>> not > >> >>>>> >>>> necessarily anyone else's vision. And I think it's > >> >>>>> >>>> time we > >> >>>>> >>>> have > >> >>>>> >>>> some > >> >>>>> >>>> method of taking into account a diverse set of > >> >>>>> >>>> opinions for > >> >>>>> >>>> what > >> >>>>> >>>> we as > >> >>>>> >>>> a community can emphasize, how we resolve conflicts, > >> >>>>> >>>> and so > >> >>>>> >>>> on > >> >>>>> >>>> and > >> >>>>> >>>> so > >> >>>>> >>>> forth. > >> >>>>> >>>> > >> >>>>> >>>> Again, thanks for bringing this up. We need to have > >> >>>>> >>>> this > >> >>>>> >>>> conversation. > >> >>>>> >>>> > >> >>>>> >>>> -Matt > >> >>>>> >>>> > >> >>>>> >>>> On Tue, Aug 12, 2014 at 4:11 PM, Britton Smith > >> >>>>> >>>> > >> >>>>> >>>> wrote: > >> >>>>> >>>>> Greeting yt developers, > >> >>>>> >>>>> > >> >>>>> >>>>> First, I want to congratulate everyone here on the > >> >>>>> >>>>> successful > >> >>>>> >>>>> release > >> >>>>> >>>>> of yt-3.0. This was a massive effort on the part of > >> >>>>> >>>>> so > >> >>>>> >>>>> many > >> >>>>> >>>>> and > >> >>>>> >>>>> a > >> >>>>> >>>>> true testament to the strength of this team. > >> >>>>> >>>>> > >> >>>>> >>>>> At the time of writing this, there are 78 members of > >> >>>>> >>>>> the > >> >>>>> >>>>> yt-dev > >> >>>>> >>>>> mailing list. As someone who does most of their work > >> >>>>> >>>>> in > >> >>>>> >>>>> very > >> >>>>> >>>>> small > >> >>>>> >>>>> collaborations, this amazes me and make me very > >> >>>>> >>>>> proud. In > >> >>>>> >>>>> case > >> >>>>> >>>>> you're > >> >>>>> >>>>> wondering, the yt-users list has 268 members. > >> >>>>> >>>>> > >> >>>>> >>>>> As a project, yt has a significant amount of > >> >>>>> >>>>> infrastructure: > >> >>>>> >>>>> code > >> >>>>> >>>>> review with pull requests, issue tracking, automated > >> >>>>> >>>>> testing, > >> >>>>> >>>>> emails > >> >>>>> >>>>> lists, an IRC channel, enhancement proposals, > >> >>>>> >>>>> workshops. > >> >>>>> >>>>> All > >> >>>>> >>>>> of > >> >>>>> >>>>> this > >> >>>>> >>>>> is evidence of our legitimacy as a Real Thing. > >> >>>>> >>>>> However, > >> >>>>> >>>>> one > >> >>>>> >>>>> big > >> >>>>> >>>>> missing piece is a system of governance. I don't > >> >>>>> >>>>> know > >> >>>>> >>>>> exactly > >> >>>>> >>>>> what > >> >>>>> >>>>> this means, but I have some ideas, which I will share > >> >>>>> >>>>> below. > >> >>>>> >>>>> What I > >> >>>>> >>>>> want to do right now is to start a discussion that > >> >>>>> >>>>> will, > >> >>>>> >>>>> hopefully, > >> >>>>> >>>>> include as many people as possible on this list. > >> >>>>> >>>>> > >> >>>>> >>>>> For me, governance means (roughly) the following: > >> >>>>> >>>>> > >> >>>>> >>>>> - a set of procedures in writing for how various > >> >>>>> >>>>> things > >> >>>>> >>>>> are to > >> >>>>> >>>>> be > >> >>>>> >>>>> done, such as acceptance of pull requests, releases, > >> >>>>> >>>>> designating > >> >>>>> >>>>> developers as core contributors, etc. > >> >>>>> >>>>> > >> >>>>> >>>>> - a governing body to make decisions and help guide > >> >>>>> >>>>> the > >> >>>>> >>>>> project. > >> >>>>> >>>>> > >> >>>>> >>>>> This accomplishes a number of things, which as a > >> >>>>> >>>>> project I > >> >>>>> >>>>> think > >> >>>>> >>>>> we > >> >>>>> >>>>> need, such as: > >> >>>>> >>>>> > >> >>>>> >>>>> - overall stability of the project. > >> >>>>> >>>>> > >> >>>>> >>>>> - providing a system for conflict resolution. > >> >>>>> >>>>> > >> >>>>> >>>>> - maintaining the spirit of yt as a team effort. > >> >>>>> >>>>> > >> >>>>> >>>>> - providing a way for active contributors to get > >> >>>>> >>>>> credit > >> >>>>> >>>>> for > >> >>>>> >>>>> their > >> >>>>> >>>>> contribution in the form of official recognition. > >> >>>>> >>>>> > >> >>>>> >>>>> > >> >>>>> >>>>> So, these are my initial thoughts, but I really think > >> >>>>> >>>>> this > >> >>>>> >>>>> deserves a > >> >>>>> >>>>> thorough discussion with as many people participating > >> >>>>> >>>>> as > >> >>>>> >>>>> possible. > >> >>>>> >>>>> Please, think about what governance means to you, > >> >>>>> >>>>> whether > >> >>>>> >>>>> we > >> >>>>> >>>>> need > >> >>>>> >>>>> it, > >> >>>>> >>>>> what it should be, and what we might get out of it, > >> >>>>> >>>>> and > >> >>>>> >>>>> share > >> >>>>> >>>>> your > >> >>>>> >>>>> thoughts over the next few days. I look forward to > >> >>>>> >>>>> this > >> >>>>> >>>>> discussion. > >> >>>>> >>>>> > >> >>>>> >>>>> Britton > >> >>>>> >>>>> > >> >>>>> >>>>> > >> >>>>> >>>>> _______________________________________________ > >> >>>>> >>>>> yt-dev mailing list > >> >>>>> >>>>> yt-dev@lists.spacepope.org > >> >>>>> >>>>> > >> >>>>> >>>>> > >> >>>>> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>>> >>>> _______________________________________________ > >> >>>>> >>>> yt-dev mailing list > >> >>>>> >>>> yt-dev@lists.spacepope.org > >> >>>>> >>>> > >> >>>>> >>>> > >> >>>>> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>>> >>> > >> >>>>> >>> > >> >>>>> >>> > >> >>>>> >>> _______________________________________________ > >> >>>>> >>> yt-dev mailing list > >> >>>>> >>> yt-dev@lists.spacepope.org > >> >>>>> >>> > >> >>>>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> -- > >> >>>>> >> Michael Zingale > >> >>>>> >> Associate Professor > >> >>>>> >> > >> >>>>> >> Dept. of Physics & Astronomy • Stony Brook University • > >> >>>>> >> Stony > >> >>>>> >> Brook, > >> >>>>> >> NY > >> >>>>> >> 11794-3800 > >> >>>>> >> phone: 631-632-8225 > >> >>>>> >> e-mail: Michael.Zingale@stonybrook.edu > >> >>>>> >> web: http://www.astro.sunysb.edu/mzingale > >> >>>>> >> > >> >>>>> >> _______________________________________________ > >> >>>>> >> yt-dev mailing list > >> >>>>> >> yt-dev@lists.spacepope.org > >> >>>>> >> > >> >>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>>> > _______________________________________________ > >> >>>>> > yt-dev mailing list > >> >>>>> > yt-dev@lists.spacepope.org > >> >>>>> > > >> >>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>>> _______________________________________________ > >> >>>>> yt-dev mailing list > >> >>>>> yt-dev@lists.spacepope.org > >> >>>>> > >> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>> > >> >>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> yt-dev mailing list > >> >>>> yt-dev@lists.spacepope.org > >> >>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>>> > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> yt-dev mailing list > >> >>> yt-dev@lists.spacepope.org > >> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> >>> > >> >> > >> > > >> > > >> > _______________________________________________ > >> > yt-dev mailing list > >> > yt-dev@lists.spacepope.org > >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >> > > >> _______________________________________________ > >> yt-dev mailing list > >> yt-dev@lists.spacepope.org > >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > > > > > _______________________________________________ > > yt-dev mailing list > > yt-dev@lists.spacepope.org > > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (12)
-
Anthony Scopatz
-
B.W. Keller
-
Brian O'Shea
-
Britton Smith
-
Cameron Hummels
-
Chris Malone
-
John Wise
-
Kenza Arraki
-
Matthew Turk
-
Michael Zingale
-
Nathan Goldbaum
-
Sam Skillman