New governance model #703
Comments
|
I would lean towards the third option; Establish a sponsorship, hoping to keep AutoFixture at the same fine quality it currently is. |
|
@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:
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. |
|
I've been around and helping on |
|
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? |
|
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! |
|
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. |
|
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 ( 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. |
|
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:
Wouldn't it satisfy everyone's needs? |
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. |
|
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). |
|
Why is the signing key kept secret? |
|
What's the point of signing anything if the signature key isn't secret? |
|
I can see where this is leading. I now ask:
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. |
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.. |
|
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.) |
|
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. |
|
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. |
|
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. |
|
@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.. |
|
@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. |
|
@ecampidoglio, do you agree with what I propose here? 😃 |
|
@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? |
|
@zvirja, it looks like @ecampidoglio is (and will be more) busy (in a great way) so let's wait him for another week 😄 🎉 |
|
@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 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 😉 |
|
@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. 👍 🥇 💯 |
|
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 @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. |
|
@zvirja, fine by me 👍 Thank you for all the hard work you are doing. |
|
@zvirja fine by me too :) |
|
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. |
|
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? |
👍 Fine by me. |
|
Thanks Nikos! 🎢 @adamchester Could you please also vote? |
|
Agreed, yes 👍 |
|
@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. |
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:
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.
The text was updated successfully, but these errors were encountered: