New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New governance model #703

Closed
ploeh opened this Issue Sep 5, 2016 · 98 comments

Comments

@ploeh
Member

ploeh commented Sep 5, 2016

AutoFixture needs a new governance model. From it's humble beginnings in 2009, I've been using the benevolent dictator governance model, and for many years, this has worked well (in my opinion).

It's always been my responsibility to steer AutoFixture in the direction of my vision. For the last couple of years, however, I've lost the vision for AutoFixture. In my opinion, it's done. I don't need it to do more than it already does.

This is exacerbated by the fact that I rarely write C# code anymore. While I could use AutoFixture in F#, I prefer FsCheck instead.

Running the AutoFixture project has always been a labour of love for me. Increasingly, however, I find that I've lost the passion. Recent contributors have probably felt this, and for that, I apologise.

It's time to try something else in order to enable the project to move forward. I can think of at least three options, but I'm open to more:

  • Continue with the benevolent dictator governance model, but with a new leader. This person must be someone willing to take on the responsibility associated with that role, as well as be someone the AutoFixture community trusts with that role. This could be one of the current core contributors to AutoFixture (@adamchester, @ecampidoglio, @moodmosaic), but could also be someone coming in from the outside.
  • Establish a new governance model. It'll be up to the people taking over to decide which one.
  • Establish a sponsorship. While I've lost the passion for AutoFixture, I still care about it, and would be willing to continue if compensated. Managing AutoFixture has never been a full-time job, so I don't expect a big sum; frankly, I don't expect this option to be realistic, but if I don't ask, the answer is automatically no 😉

Obviously, I'll be happy to assist handing over the responsibilities of the project to someone else. You may, for example, wonder how to build, sign, and release new NuGet packages. It's easy, but you'll need the signing key.

It's been great leading AutoFixture for all those years. It's a project that I originally created and nurtured. It's difficult to let go 😢

My hope is that this is like a child growing up, now becoming mature enough to move on without his or her parents.

@moodmosaic

This comment has been minimized.

Show comment
Hide comment
@moodmosaic

moodmosaic Sep 7, 2016

Member

I would lean towards the third option; Establish a sponsorship, hoping to keep AutoFixture at the same fine quality it currently is.

Member

moodmosaic commented Sep 7, 2016

I would lean towards the third option; Establish a sponsorship, hoping to keep AutoFixture at the same fine quality it currently is.

@Mykezero

This comment has been minimized.

Show comment
Hide comment
@Mykezero

Mykezero Sep 9, 2016

Contributor

@ploeh Thank you for all the hard work and dedication you've put into this project! Of course, I would always be willing to sponsor you by buying you those cups of coffee ^^

In my opinion, the benevolent dictator model could work if one of the core contributors has the following:

  1. A future vision for the project with a direction of where AutoFixture is heading towards.
  2. The passion for the project along with a long term commitment to its community.
  3. The technical understanding of AutoFixture as a whole.
  4. A willingness to do that work that must be done to drive toward that future vision.

If that's not the case, then a new model where the core contributors are in charge of making the decisions for what should and shouldn't be done in the project. This would require a shared vision for the future of AutoFixture, and a lot of communication to discuss new changes within the project.

Hopefully I've hit on a few key notes with regards to a new governance model, and that my comments aren't totally out of sync with the realities of running an open source project.

Contributor

Mykezero commented Sep 9, 2016

@ploeh Thank you for all the hard work and dedication you've put into this project! Of course, I would always be willing to sponsor you by buying you those cups of coffee ^^

In my opinion, the benevolent dictator model could work if one of the core contributors has the following:

  1. A future vision for the project with a direction of where AutoFixture is heading towards.
  2. The passion for the project along with a long term commitment to its community.
  3. The technical understanding of AutoFixture as a whole.
  4. A willingness to do that work that must be done to drive toward that future vision.

If that's not the case, then a new model where the core contributors are in charge of making the decisions for what should and shouldn't be done in the project. This would require a shared vision for the future of AutoFixture, and a lot of communication to discuss new changes within the project.

Hopefully I've hit on a few key notes with regards to a new governance model, and that my comments aren't totally out of sync with the realities of running an open source project.

@moodmosaic

This comment has been minimized.

Show comment
Hide comment
@moodmosaic

moodmosaic Sep 12, 2016

Member

I've been around and helping on 2. and 3., on and off since mid-2011, and I'd be happy to continue doing so.

Member

moodmosaic commented Sep 12, 2016

I've been around and helping on 2. and 3., on and off since mid-2011, and I'd be happy to continue doing so.

@ecampidoglio

This comment has been minimized.

Show comment
Hide comment
@ecampidoglio

ecampidoglio Sep 12, 2016

Member

As much as it pains me to see this era of AutoFixture come to an end, I fully understand @ploeh's motivations for stepping down as the project's leader. Thank you for the huge time and effort you've invested in AutoFixture, Mark! Not to mention the knowledge that you've shared in your code reviews — I've learned tons from those alone!

For me, AutoFixture remains a tool that I use almost daily and I'd like to see it continue to improve. Like @moodmosaic, I've been contributing — albeit to a lesser extent — since 2011 and I, too, intend to remain committed going forward.

Having said that, I must admit that I don't feel I have the necessary vision to lead the project. Sure, I have a few ideas; for example, it would be nice to have a smaller and more straightforward API (right now there are multiple ways of achieving the same thing, with various degrees of discoverability). But that's far from being a well-defined goal. More like a general direction, at best.

So here's my proposal: we drop the individual leader model and instead offload those responsibilities to the @AutoFixture/core team as a whole. I think the group is small and experienced enough to be able to handle future design decisions together.

What do you guys think?

Member

ecampidoglio commented Sep 12, 2016

As much as it pains me to see this era of AutoFixture come to an end, I fully understand @ploeh's motivations for stepping down as the project's leader. Thank you for the huge time and effort you've invested in AutoFixture, Mark! Not to mention the knowledge that you've shared in your code reviews — I've learned tons from those alone!

For me, AutoFixture remains a tool that I use almost daily and I'd like to see it continue to improve. Like @moodmosaic, I've been contributing — albeit to a lesser extent — since 2011 and I, too, intend to remain committed going forward.

Having said that, I must admit that I don't feel I have the necessary vision to lead the project. Sure, I have a few ideas; for example, it would be nice to have a smaller and more straightforward API (right now there are multiple ways of achieving the same thing, with various degrees of discoverability). But that's far from being a well-defined goal. More like a general direction, at best.

So here's my proposal: we drop the individual leader model and instead offload those responsibilities to the @AutoFixture/core team as a whole. I think the group is small and experienced enough to be able to handle future design decisions together.

What do you guys think?

@sergeyshushlyapin

This comment has been minimized.

Show comment
Hide comment
@sergeyshushlyapin

sergeyshushlyapin Sep 13, 2016

Contributor

I can only say thank you @ploeh, @moodmosaic, @ecampidoglio and @adamchester for reviewing my pull requests! Usually it was quite challenging 😉, but I appreciate your input and continuous knowledge sharing!

I really enjoyed contributing to AutoFixture and "I Don't Wanna Stop" (c). I do believe the core team will continue doing their excellent job. Well done, guys!

Contributor

sergeyshushlyapin commented Sep 13, 2016

I can only say thank you @ploeh, @moodmosaic, @ecampidoglio and @adamchester for reviewing my pull requests! Usually it was quite challenging 😉, but I appreciate your input and continuous knowledge sharing!

I really enjoyed contributing to AutoFixture and "I Don't Wanna Stop" (c). I do believe the core team will continue doing their excellent job. Well done, guys!

@bjorn-ali-goransson

This comment has been minimized.

Show comment
Hide comment
@bjorn-ali-goransson

bjorn-ali-goransson Oct 22, 2016

No vision is better than a bad vision. Which is why I'd (spontaneously) prefer someone similar to @ecampidoglio to lead the project, even if (if) this would mean that it almost goes into maintenance mode.

("Promote a leader who above all would not wish leadership" as we muslims say)

Furthermore, if AF turns into something else because of the new dictator´s vision, then the original AF would soon again be without dictator. So, let's value a relative status quo for a while, to consolidate.

Not to show disrespect your efforts, Mark, but let's not forget the old question of the ploeh namespace prefix, while you're still onboard.

bjorn-ali-goransson commented Oct 22, 2016

No vision is better than a bad vision. Which is why I'd (spontaneously) prefer someone similar to @ecampidoglio to lead the project, even if (if) this would mean that it almost goes into maintenance mode.

("Promote a leader who above all would not wish leadership" as we muslims say)

Furthermore, if AF turns into something else because of the new dictator´s vision, then the original AF would soon again be without dictator. So, let's value a relative status quo for a while, to consolidate.

Not to show disrespect your efforts, Mark, but let's not forget the old question of the ploeh namespace prefix, while you're still onboard.

@ploeh

This comment has been minimized.

Show comment
Hide comment
@ploeh

ploeh Dec 6, 2016

Member

Revisiting this thread three months later, it looks like AutoFixture is stuck. I did realise, however, that if anyone wants to take over the reins, they'd need at least two things from me: the signing key (.snk) and publish rights to the NuGet packages. With these, I believe, someone else should be able to publish new versions of AutoFixture.

Contact me if you'd like to have these transferred to you. Do understand, however, that I will regard any such transfer as an official transfer of the rights, as well as the responsibilities, of future maintenance of AutoFixture.

Member

ploeh commented Dec 6, 2016

Revisiting this thread three months later, it looks like AutoFixture is stuck. I did realise, however, that if anyone wants to take over the reins, they'd need at least two things from me: the signing key (.snk) and publish rights to the NuGet packages. With these, I believe, someone else should be able to publish new versions of AutoFixture.

Contact me if you'd like to have these transferred to you. Do understand, however, that I will regard any such transfer as an official transfer of the rights, as well as the responsibilities, of future maintenance of AutoFixture.

@sergeyshushlyapin

This comment has been minimized.

Show comment
Hide comment
@sergeyshushlyapin

sergeyshushlyapin Jan 26, 2017

Contributor

To keep balance between @ploeh's desire to depart away from AutoFixture and the community desire to get new versions (see amount of links to another PBIs in this thread), I would like to suggest the following workflow:

  1. Core contributors (@ecampidoglio, @moodmosaic or @adamchester) review and discuss coming pull requests.
  2. As soon as they are done with review and a PR is ready to be merged, they signal to @ploeh.
  3. @ploeh in any suitable for him time simply pulls the trigger and release a new version without getting into release details.

Wouldn't it satisfy everyone's needs?

Contributor

sergeyshushlyapin commented Jan 26, 2017

To keep balance between @ploeh's desire to depart away from AutoFixture and the community desire to get new versions (see amount of links to another PBIs in this thread), I would like to suggest the following workflow:

  1. Core contributors (@ecampidoglio, @moodmosaic or @adamchester) review and discuss coming pull requests.
  2. As soon as they are done with review and a PR is ready to be merged, they signal to @ploeh.
  3. @ploeh in any suitable for him time simply pulls the trigger and release a new version without getting into release details.

Wouldn't it satisfy everyone's needs?

@moodmosaic

This comment has been minimized.

Show comment
Hide comment
@moodmosaic

moodmosaic Jan 26, 2017

Member
  1. Core contributors (@ecampidoglio, @moodmosaic or @adamchester) review and discuss coming pull requests.

Fine by me, if I have the required knowledge to review the PR(s). Usually, I (happily) review parts of the code-base where I have previously worked on, created, or contributed.

Member

moodmosaic commented Jan 26, 2017

  1. Core contributors (@ecampidoglio, @moodmosaic or @adamchester) review and discuss coming pull requests.

Fine by me, if I have the required knowledge to review the PR(s). Usually, I (happily) review parts of the code-base where I have previously worked on, created, or contributed.

@ploeh

This comment has been minimized.

Show comment
Hide comment
@ploeh

ploeh Jan 26, 2017

Member

Since I added this issue months ago, few people have noticed it. Most people still think that I'm the benevolent dictator of AutoFixture.

The model suggested by @sergeyshushlyapin will only confuse matters. It has to be clear to contributors what the governance model is, and who's making decisions.

The only thing required of me in that suggested model is that I perform some routine operations. It's nothing more than 5-10 steps in the Git Bash, and I'll be happy to teach someone else to go through those motions instead of me. There's no reason it has to be me, other than currently, as explained above, I'm the only person in possesion of the keys to the resources.

The model suggested will, de facto, put the responsibility on @moodmosaic, @ecampidoglio, and @adamchester. If they are fine with that, they should also take on the formal responsibility. All of them could get my keys, and thereby sharing the responsibility, but I'm not interested in retaining formal responsibility (unless a sponsorship pops up).

Member

ploeh commented Jan 26, 2017

Since I added this issue months ago, few people have noticed it. Most people still think that I'm the benevolent dictator of AutoFixture.

The model suggested by @sergeyshushlyapin will only confuse matters. It has to be clear to contributors what the governance model is, and who's making decisions.

The only thing required of me in that suggested model is that I perform some routine operations. It's nothing more than 5-10 steps in the Git Bash, and I'll be happy to teach someone else to go through those motions instead of me. There's no reason it has to be me, other than currently, as explained above, I'm the only person in possesion of the keys to the resources.

The model suggested will, de facto, put the responsibility on @moodmosaic, @ecampidoglio, and @adamchester. If they are fine with that, they should also take on the formal responsibility. All of them could get my keys, and thereby sharing the responsibility, but I'm not interested in retaining formal responsibility (unless a sponsorship pops up).

@blairconrad blairconrad referenced this issue Feb 16, 2017

Closed

3.0.0 release #902

19 of 19 tasks complete
@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Feb 16, 2017

Contributor

Why is the signing key kept secret?

Contributor

adamralph commented Feb 16, 2017

Why is the signing key kept secret?

@ploeh

This comment has been minimized.

Show comment
Hide comment
@ploeh

ploeh Feb 16, 2017

Member

What's the point of signing anything if the signature key isn't secret?

Member

ploeh commented Feb 16, 2017

What's the point of signing anything if the signature key isn't secret?

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Feb 16, 2017

Contributor

I can see where this is leading. I now ask:

What's the point of signing anything?

And hey presto! We're into a signing/not-signing battle. 😉

I don't want to hijack this issue. That war is being waged elsewhere. Sorry for mentioning it.

Contributor

adamralph commented Feb 16, 2017

I can see where this is leading. I now ask:

What's the point of signing anything?

And hey presto! We're into a signing/not-signing battle. 😉

I don't want to hijack this issue. That war is being waged elsewhere. Sorry for mentioning it.

@ploeh

This comment has been minimized.

Show comment
Hide comment
@ploeh

ploeh Feb 16, 2017

Member

We're into a signing/not-signing battle.

That wasn't really my intention; sorry. I don't have a hard opinion about that debate. To be frank, I still can't fully get my head around it, because there's so much wrong information being thrown around between the correct information... I have a hard time separating the signal from the noise, so I tend to favour keeping things that have been working for years as they are...

AutoFixture is fairly old, and it's always been signed by that key. Microsoft strongly recommended it back then..

Member

ploeh commented Feb 16, 2017

We're into a signing/not-signing battle.

That wasn't really my intention; sorry. I don't have a hard opinion about that debate. To be frank, I still can't fully get my head around it, because there's so much wrong information being thrown around between the correct information... I have a hard time separating the signal from the noise, so I tend to favour keeping things that have been working for years as they are...

AutoFixture is fairly old, and it's always been signed by that key. Microsoft strongly recommended it back then..

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Feb 16, 2017

Contributor

I wouldn't un-sign it now. The problem with that is that the assembly identity would change, so things like binding redirects would no longer work. I'm also looking after some projects which were signed back in the day and I've resigned myself to the fact that I'll just have to keep them signed forever. Oh, and there's also the problem of virality. I.e. another reason I can't un-sign those projects is that there may be signed projects out there that depend on them.

OK, one last word on the secret key: have you considered what you would do if the key became compromised? Changing the key would also change the assembly identity. (log4net actually made the decision to do this in order to make their key secret, and it caused no end of problems.)

Contributor

adamralph commented Feb 16, 2017

I wouldn't un-sign it now. The problem with that is that the assembly identity would change, so things like binding redirects would no longer work. I'm also looking after some projects which were signed back in the day and I've resigned myself to the fact that I'll just have to keep them signed forever. Oh, and there's also the problem of virality. I.e. another reason I can't un-sign those projects is that there may be signed projects out there that depend on them.

OK, one last word on the secret key: have you considered what you would do if the key became compromised? Changing the key would also change the assembly identity. (log4net actually made the decision to do this in order to make their key secret, and it caused no end of problems.)

@ploeh

This comment has been minimized.

Show comment
Hide comment
@ploeh

ploeh Feb 16, 2017

Member

Good point about the key becoming compromised. It looks like it's a moot point for AutoFixture now, but if it ever happened, my first reaction would be to exchange the key with a new one. Since that changes the identity of the assembly, we'd have to increment the major version.

I suppose another alternative at that point would be to stop signing the assembly altogether, but that would still require a new major version.

Member

ploeh commented Feb 16, 2017

Good point about the key becoming compromised. It looks like it's a moot point for AutoFixture now, but if it ever happened, my first reaction would be to exchange the key with a new one. Since that changes the identity of the assembly, we'd have to increment the major version.

I suppose another alternative at that point would be to stop signing the assembly altogether, but that would still require a new major version.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Feb 16, 2017

Contributor

That's what log4net did, but it didn't work out well. It caused considerable pain and confusion for consuming apps and dependent packages. (I gave up and dropped log4net.) I don't know how much of a problem it would be for AutoFac though.

Since the identity of the assembly changes, it's not a new entry in the version history of the assembly. It's the start of the version history for a new assembly. If a key must be secret, but becomes compromised, then it's not possible to release a new version of the assembly.

Contributor

adamralph commented Feb 16, 2017

That's what log4net did, but it didn't work out well. It caused considerable pain and confusion for consuming apps and dependent packages. (I gave up and dropped log4net.) I don't know how much of a problem it would be for AutoFac though.

Since the identity of the assembly changes, it's not a new entry in the version history of the assembly. It's the start of the version history for a new assembly. If a key must be secret, but becomes compromised, then it's not possible to release a new version of the assembly.

@moodmosaic

This comment has been minimized.

Show comment
Hide comment
@moodmosaic

moodmosaic Sep 1, 2017

Member

@zvirja, I'd suggest we wait for all (@ecampidoglio, @adamchester, and @klimisa) to agree on this, if possible.

Specially @ecampidoglio and @adamchester who have been around for years. I'm not sure if @klimisa has been active at all, to be honest (?)

Member

moodmosaic commented Sep 1, 2017

@zvirja, I'd suggest we wait for all (@ecampidoglio, @adamchester, and @klimisa) to agree on this, if possible.

Specially @ecampidoglio and @adamchester who have been around for years. I'm not sure if @klimisa has been active at all, to be honest (?)

@zvirja

This comment has been minimized.

Show comment
Hide comment
@zvirja

zvirja Sep 1, 2017

Member

@moodmosaic Sure, that's exactly how I planned that.

Specially @ecampidoglio and @adamchester who have been around for years.

Hope @ecampidoglio will arrive in the nearby future to reply - he was totally absent for the last months..

I'm not sure if @klimisa has been active at all, to be honest (?)

That's the point that causes a bit of confusion to me. I saw very rare @klimisa's activity in PRs and this thread, however I mostly have a feeling that he doesn't participate. Given that he doesn't strong background within the project, could we consider his vote as optional? Meaning if he didn't reply - we proceed with what we have.

Member

zvirja commented Sep 1, 2017

@moodmosaic Sure, that's exactly how I planned that.

Specially @ecampidoglio and @adamchester who have been around for years.

Hope @ecampidoglio will arrive in the nearby future to reply - he was totally absent for the last months..

I'm not sure if @klimisa has been active at all, to be honest (?)

That's the point that causes a bit of confusion to me. I saw very rare @klimisa's activity in PRs and this thread, however I mostly have a feeling that he doesn't participate. Given that he doesn't strong background within the project, could we consider his vote as optional? Meaning if he didn't reply - we proceed with what we have.

@klimisa

This comment has been minimized.

Show comment
Hide comment
@klimisa

klimisa Sep 3, 2017

AutoFixture has been very active the last few months, try to get to v.4 and by maintaining the existing codebase. At the moment the rate of changes happens and the time I have in order to catch up, do not align.

Presuming that more people are needed with a bit of more time than mine, I decided to leave the project. Therefore, I'm kindly asking @zvirja to withdraw my credentials from Github and from NuGet.

I will still follow the project and watch the changes but without the time pressure that it has now.

Many thanks to @ploeh and @AutoFixture/core. Special thanks to @zvirja for all the work he is doing.

klimisa commented Sep 3, 2017

AutoFixture has been very active the last few months, try to get to v.4 and by maintaining the existing codebase. At the moment the rate of changes happens and the time I have in order to catch up, do not align.

Presuming that more people are needed with a bit of more time than mine, I decided to leave the project. Therefore, I'm kindly asking @zvirja to withdraw my credentials from Github and from NuGet.

I will still follow the project and watch the changes but without the time pressure that it has now.

Many thanks to @ploeh and @AutoFixture/core. Special thanks to @zvirja for all the work he is doing.

@adamchester

This comment has been minimized.

Show comment
Hide comment
@adamchester

adamchester Sep 3, 2017

Member

I agree with the proposal here

Also, I didn't mean to suggest that no PR should happen, but I do of course agree that we should be able to move forward on the build changes without review if nobody has the ability or time to review them in depth.

Sorry I've been a little busy lately again, I'm trying to keep one eye on various the changes where I can.

Member

adamchester commented Sep 3, 2017

I agree with the proposal here

Also, I didn't mean to suggest that no PR should happen, but I do of course agree that we should be able to move forward on the build changes without review if nobody has the ability or time to review them in depth.

Sorry I've been a little busy lately again, I'm trying to keep one eye on various the changes where I can.

@zvirja

This comment has been minimized.

Show comment
Hide comment
@zvirja

zvirja Sep 4, 2017

Member

@klimisa It's a pity to hear that you don't have free time for that and decided to leave the project 😞😢 However, I do understand that decision and we indeed are doing a lot. Thank you for all the activity you did and time you spent on this project and thanks for be my colleague in the Release Management group 😄

If you have time in future, feel free to get back and contribute further to the project. Given the number of things need to be done we definitely need one more pair of hands!

@adamchester Thanks for the approval! As it has been agreed here I'll still create PRs for better history readability, however will simply not require an approval for that.

@ecampidoglio You are the only one who left for the vote for this proposal - @moodmosaic and @adamchester agreed. Could you please confirm that you are also fine? Hope, you will appear in the nearby future to vote so we can proceed further..

Member

zvirja commented Sep 4, 2017

@klimisa It's a pity to hear that you don't have free time for that and decided to leave the project 😞😢 However, I do understand that decision and we indeed are doing a lot. Thank you for all the activity you did and time you spent on this project and thanks for be my colleague in the Release Management group 😄

If you have time in future, feel free to get back and contribute further to the project. Given the number of things need to be done we definitely need one more pair of hands!

@adamchester Thanks for the approval! As it has been agreed here I'll still create PRs for better history readability, however will simply not require an approval for that.

@ecampidoglio You are the only one who left for the vote for this proposal - @moodmosaic and @adamchester agreed. Could you please confirm that you are also fine? Hope, you will appear in the nearby future to vote so we can proceed further..

@zvirja

This comment has been minimized.

Show comment
Hide comment
@zvirja

zvirja Sep 7, 2017

Member

@moodmosaic It seems that @ecampidoglio is still very busy to participate in this project and put his reply. Given that there is no sense of ETA when he will arrive back, may I consider the proposal above as confirmed, so I can proceed further and merge #811 (which was created about 2 weeks ago)?

Notice, as I previously mentioned, I'll apply only insignificant house keeping changes and for major ones (like with the logging verbosity) I'll ask you to participate.

Member

zvirja commented Sep 7, 2017

@moodmosaic It seems that @ecampidoglio is still very busy to participate in this project and put his reply. Given that there is no sense of ETA when he will arrive back, may I consider the proposal above as confirmed, so I can proceed further and merge #811 (which was created about 2 weeks ago)?

Notice, as I previously mentioned, I'll apply only insignificant house keeping changes and for major ones (like with the logging verbosity) I'll ask you to participate.

@moodmosaic

This comment has been minimized.

Show comment
Hide comment
@moodmosaic

moodmosaic Sep 8, 2017

Member

@ecampidoglio, do you agree with what I propose here? 😃

Member

moodmosaic commented Sep 8, 2017

@ecampidoglio, do you agree with what I propose here? 😃

@zvirja

This comment has been minimized.

Show comment
Hide comment
@zvirja

zvirja Sep 12, 2017

Member

@moodmosaic It seems that your summon didn't help a lot 😄

Given that, could we proceed further as in any case we have nobody available to review those changes?

Member

zvirja commented Sep 12, 2017

@moodmosaic It seems that your summon didn't help a lot 😄

Given that, could we proceed further as in any case we have nobody available to review those changes?

@moodmosaic

This comment has been minimized.

Show comment
Hide comment
@moodmosaic

moodmosaic Sep 13, 2017

Member

@zvirja, it looks like @ecampidoglio is (and will be more) busy (in a great way) so let's wait him for another week 😄 🎉

Member

moodmosaic commented Sep 13, 2017

@zvirja, it looks like @ecampidoglio is (and will be more) busy (in a great way) so let's wait him for another week 😄 🎉

@zvirja

This comment has been minimized.

Show comment
Hide comment
@zvirja

zvirja Sep 13, 2017

Member

@moodmosaic Let me speak fairly. While I do understand your intention, the options are unclear to me. Given that Enrico has been already missing for couple months and you expect that he will be even more busy, who is expected to review such PRs?

Currently you @moodmosaic and @adamchester are pretty overwhelmed with your work (and probably external life 😄). The time you can allocate for this project is hardly enough to cover the PRs with important changes. For instance, we have this PR that has been opened 2 weeks ago and nobody had a chance to review it. I understand that we are not paid for the work we do so it's fine. Be sure that I respect your attention and am very thankful for that! 🏅🥇However all we should clearly understand that existing reviewers capacity is not enough to cover the housekeeping.

In order to make things simpler I suggested an addition to what we already agreed - to able to modify the csproj and sln files as well. Build scripts and solution files are closely related to each other and e.g. to improve xUnit tests invocation (to get rid of this ugly list) I need to apply changes in test projects by installing an additional xunit packages to some projects. This changes are insignificant and they will make things simpler - all our test projects will be aligned.

It's a bit unclear to me what is special about this last rule so that 2 votes are strongly not enough. Previously we successfully agreed on other rules having 2 votes only.

Honestly, I'm a bit frustrated by this. I'm participating here for about half of a year now and did a lot of stuff. I have a lot of intention and readiness to move us further by actively participating in different issue and PR discussions. I think that I did enough to prove that I fully understand what I'm doing; I have clear intentions; I try analyze all the potential outcomes; I respect the spirit of the OSS project where the important changes should be discussed; I understand that my experience might be not enough so I'm always open for your opinions and I learn them. However, for me it looks like you suspect that I'll start to make a mess here if I get such permissions and don't trust me that I'll create a PR when I change something potentially significant 😞

Previously you mentioned that you are afraid that I could lose a passion and you will need to support all this by yourself. I don't see this as an issue actually. That is what already happened when Mark left this project - we had the similar situation when somebody else needed to learn how things are organized and continue to support them. That time we had me who picked that up and learned. I believe that even if I lose the passion, that will not be an issue and a new person will learn the project layout and build pipeline in a day or so. Actually, there less chances that I'll leave this project if I feel that I'm a part of the team and have an area I "own" and can care of 😊

Sorry if my answer is a bit emotional, however I felt that it's better to clearly discuss that. It will allow us to move ahead or at least be aligned. And, of course, I'm happy to participate in this project and am willing to continue to do this 😉

Member

zvirja commented Sep 13, 2017

@moodmosaic Let me speak fairly. While I do understand your intention, the options are unclear to me. Given that Enrico has been already missing for couple months and you expect that he will be even more busy, who is expected to review such PRs?

Currently you @moodmosaic and @adamchester are pretty overwhelmed with your work (and probably external life 😄). The time you can allocate for this project is hardly enough to cover the PRs with important changes. For instance, we have this PR that has been opened 2 weeks ago and nobody had a chance to review it. I understand that we are not paid for the work we do so it's fine. Be sure that I respect your attention and am very thankful for that! 🏅🥇However all we should clearly understand that existing reviewers capacity is not enough to cover the housekeeping.

In order to make things simpler I suggested an addition to what we already agreed - to able to modify the csproj and sln files as well. Build scripts and solution files are closely related to each other and e.g. to improve xUnit tests invocation (to get rid of this ugly list) I need to apply changes in test projects by installing an additional xunit packages to some projects. This changes are insignificant and they will make things simpler - all our test projects will be aligned.

It's a bit unclear to me what is special about this last rule so that 2 votes are strongly not enough. Previously we successfully agreed on other rules having 2 votes only.

Honestly, I'm a bit frustrated by this. I'm participating here for about half of a year now and did a lot of stuff. I have a lot of intention and readiness to move us further by actively participating in different issue and PR discussions. I think that I did enough to prove that I fully understand what I'm doing; I have clear intentions; I try analyze all the potential outcomes; I respect the spirit of the OSS project where the important changes should be discussed; I understand that my experience might be not enough so I'm always open for your opinions and I learn them. However, for me it looks like you suspect that I'll start to make a mess here if I get such permissions and don't trust me that I'll create a PR when I change something potentially significant 😞

Previously you mentioned that you are afraid that I could lose a passion and you will need to support all this by yourself. I don't see this as an issue actually. That is what already happened when Mark left this project - we had the similar situation when somebody else needed to learn how things are organized and continue to support them. That time we had me who picked that up and learned. I believe that even if I lose the passion, that will not be an issue and a new person will learn the project layout and build pipeline in a day or so. Actually, there less chances that I'll leave this project if I feel that I'm a part of the team and have an area I "own" and can care of 😊

Sorry if my answer is a bit emotional, however I felt that it's better to clearly discuss that. It will allow us to move ahead or at least be aligned. And, of course, I'm happy to participate in this project and am willing to continue to do this 😉

@moodmosaic

This comment has been minimized.

Show comment
Hide comment
@moodmosaic

moodmosaic Sep 18, 2017

Member

@zvirja, I was hoping to hear back from @ecampidoglio as he was the one who suggested that all PRs should be approved by at least two people from the @AutoFixture/core team before being merged [..].

Apparently, @ecampidoglio must be busy (which is a good thing!) as the last time he commented on this thread was on Mar 29 even though he's been mentioned a couple of times after that date.

At this point, I have no idea when he's going to return, so perhaps we should move on with this, as well as being able to move on quickly with the various MSBuild files you propose here.

👍 🥇 💯

Member

moodmosaic commented Sep 18, 2017

@zvirja, I was hoping to hear back from @ecampidoglio as he was the one who suggested that all PRs should be approved by at least two people from the @AutoFixture/core team before being merged [..].

Apparently, @ecampidoglio must be busy (which is a good thing!) as the last time he commented on this thread was on Mar 29 even though he's been mentioned a couple of times after that date.

At this point, I have no idea when he's going to return, so perhaps we should move on with this, as well as being able to move on quickly with the various MSBuild files you propose here.

👍 🥇 💯

@zvirja

This comment has been minimized.

Show comment
Hide comment
@zvirja

zvirja Oct 2, 2017

Member

Recently I did a series of minor housekeeping changes for our code base: #846, #847, #850 and #852. The main point is that those changes doesn't affect the logic somehow and are mostly related to the code style.

Currently I have permissions to modify our build scripts and project related files without approval. Would you agree to extend those permissions to such kind of codebase changes as well? I mean changes related to the code style (e.g. use nameof() for argument guards), when actual logic remains the same. As usual - all changes will be done via PRs and if there are significant changes - I'll ask for the review.

@moodmosaic @adamchester @ecampidoglio Do you agree with that? That should simplify the amount of PRs that require the review and allow to focus on valuable changes only.

Member

zvirja commented Oct 2, 2017

Recently I did a series of minor housekeeping changes for our code base: #846, #847, #850 and #852. The main point is that those changes doesn't affect the logic somehow and are mostly related to the code style.

Currently I have permissions to modify our build scripts and project related files without approval. Would you agree to extend those permissions to such kind of codebase changes as well? I mean changes related to the code style (e.g. use nameof() for argument guards), when actual logic remains the same. As usual - all changes will be done via PRs and if there are significant changes - I'll ask for the review.

@moodmosaic @adamchester @ecampidoglio Do you agree with that? That should simplify the amount of PRs that require the review and allow to focus on valuable changes only.

@moodmosaic

This comment has been minimized.

Show comment
Hide comment
@moodmosaic

moodmosaic Oct 3, 2017

Member

@zvirja, fine by me 👍 Thank you for all the hard work you are doing.

Member

moodmosaic commented Oct 3, 2017

@zvirja, fine by me 👍 Thank you for all the hard work you are doing.

@adamchester

This comment has been minimized.

Show comment
Hide comment
@adamchester

adamchester Oct 3, 2017

Member

@zvirja fine by me too :)

Member

adamchester commented Oct 3, 2017

@zvirja fine by me too :)

@zvirja

This comment has been minimized.

Show comment
Hide comment
@zvirja

zvirja Oct 3, 2017

Member

Thanks for the confirmation 😎

Given that Enrico is completely absent and doesn't participate for now, I'm considering this rule as agreed. @moodmosaic @adamchester Let me know if you disagree.

Member

zvirja commented Oct 3, 2017

Thanks for the confirmation 😎

Given that Enrico is completely absent and doesn't participate for now, I'm considering this rule as agreed. @moodmosaic @adamchester Let me know if you disagree.

@zvirja

This comment has been minimized.

Show comment
Hide comment
@zvirja

zvirja Oct 23, 2017

Member

Previously we have agreed on a rule that PR can be merged if it has one approval and one week of lifetime. The reason behind this week was to give an opportunity for other reviewers to jump-in. However, since we agreed on this rule, in fact that never happened (in more than 2 months). The reality is that @moodmosaic and me are the only alive maintainers of this project at this moment of time. Therefore, this one week of delay doesn't make any sense.

Given that I have a proposal to eliminate that one week delay rule, so that PRs can be merged immediately if they have one approval. Of course, we still left the possibility for reviewers to override the rule per PR, however by default PRs will be "mergable" immediately.

@adamchester @moodmosaic What are you thoughts regarding that?

Member

zvirja commented Oct 23, 2017

Previously we have agreed on a rule that PR can be merged if it has one approval and one week of lifetime. The reason behind this week was to give an opportunity for other reviewers to jump-in. However, since we agreed on this rule, in fact that never happened (in more than 2 months). The reality is that @moodmosaic and me are the only alive maintainers of this project at this moment of time. Therefore, this one week of delay doesn't make any sense.

Given that I have a proposal to eliminate that one week delay rule, so that PRs can be merged immediately if they have one approval. Of course, we still left the possibility for reviewers to override the rule per PR, however by default PRs will be "mergable" immediately.

@adamchester @moodmosaic What are you thoughts regarding that?

@moodmosaic

This comment has been minimized.

Show comment
Hide comment
@moodmosaic

moodmosaic Oct 24, 2017

Member

so that PRs can be merged immediately if they have one approval

👍 Fine by me.

Member

moodmosaic commented Oct 24, 2017

so that PRs can be merged immediately if they have one approval

👍 Fine by me.

@zvirja

This comment has been minimized.

Show comment
Hide comment
@zvirja

zvirja Oct 24, 2017

Member

Thanks Nikos! 🎢

@adamchester Could you please also vote?

Member

zvirja commented Oct 24, 2017

Thanks Nikos! 🎢

@adamchester Could you please also vote?

@adamchester

This comment has been minimized.

Show comment
Hide comment
@adamchester

adamchester Oct 24, 2017

Member

Agreed, yes 👍

Member

adamchester commented Oct 24, 2017

Agreed, yes 👍

@moodmosaic

This comment has been minimized.

Show comment
Hide comment
@moodmosaic

moodmosaic Mar 8, 2018

Member

This comment by @ploeh helped me realize that I'm here, helping with issues, as long as the overall vision remains quite the same―I'll be pretty much useless if there's a different vision and so then I'll be out...

Member

moodmosaic commented Mar 8, 2018

This comment by @ploeh helped me realize that I'm here, helping with issues, as long as the overall vision remains quite the same―I'll be pretty much useless if there's a different vision and so then I'll be out...

@zvirja

This comment has been minimized.

Show comment
Hide comment
@zvirja

zvirja Mar 8, 2018

Member

@moodmosaic I've described my vision in my reply. As far as I can see, I still have the pretty same vision as Mark, nothing completely different. I feel that your help and experience are very valuable for the project and I'd be very happy to still see you here. It's totally fine that sometimes we might have a different vision on some things - that allows to make the best decisions.

Member

zvirja commented Mar 8, 2018

@moodmosaic I've described my vision in my reply. As far as I can see, I still have the pretty same vision as Mark, nothing completely different. I feel that your help and experience are very valuable for the project and I'd be very happy to still see you here. It's totally fine that sometimes we might have a different vision on some things - that allows to make the best decisions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment