Project maintainership #2442
Replies: 6 comments 57 replies
|
Thanks for starting this, Tom. Personally, I think radical grooming of the issues/backlog would be a great idea to start. There're a lot of issues with "needs design decision" or "needs confirmation" labels that could easily be considered out-of-scope for this project. After the grooming, it might be more clear what this project needs. While I'm not deeply familiar with the stock MkDocs themes, I'm happy to assist in evaluating frontend-related issues or feature requests as part of a joint session (via Zoom, or similar). |
|
To save time, IMHO, it makes sense to do this in one session. Unfortunately, I don't have the time to comment and discuss every open issue whether it needs closing in written form, but pairing with a maintainer who has the rights as part of a Zoom (?) call is something I could offer. And yes, converting issues to discussions is also something that could be considered in this instance. Just drop me a message on Twitter if you or somebody else wants to do it and to find a time slot. |
|
@tomchristie @squidfunk I'll be happy to participate in a joint 1-2H call to help in addressing those issues/PRs ✋ I agree with Martin that the participation of a maintainer is needed for this to be efficient so we can have an immediate impact on the project and not waste our time in asynchronous discussions. |
|
Okay, I'm up for giving that a go. |
|
@ultrabug @tomchristie I've sent you both a link to a Doodle for coordination via Twitter. |
|
@tomchristie we've been trying to reach out to you for a while with Martin. I can't seem to be allowed to message you on Twitter so I'd like to give it a shot here. Feel free to reach out (same nick on twitter) or tell us about your plan to move on, I'll do my best to make do. |
This comment was marked as disruptive content.
This comment was marked as disruptive content.
|
Okay, I can see some communication issues all round here. As it stands I don't think there's any issues currently blocked by existing team members requiring "ownership" permissions, so I'm going to hold onto the ownership keys at this point in time. If there are specific organisational issues that require resolving please just ask. I've created https://github.com/mkdocs/mkdocs-team-space as a space for us to have discussions around project maintainership etc. All existing team members currently have "maintain" permissions onto that repo, I think that ought to allow y'all to invite other plugin authors and invested parties into the space. |
This comment was marked as disruptive content.
This comment was marked as disruptive content.
This comment was marked as disruptive content.
This comment was marked as disruptive content.
This comment was marked as disruptive content.
This comment was marked as disruptive content.
|
@Andre601 I asked about this on GitHub's private maintainers community, as it is in fact showing the maintainer badge although I had my settings set to private (as I do now). No reaction from GitHub yet. It also sounds like an error to me. Additionally, I second Tom here. Everybody that is a member can start working on moving the project forward – we can merge PRs, make releases and triage issues. There's no need to be an owner right now, and it shows Tom's trust in all of us. |
|
I'm away on vacation sorry, will reply on July 12, thanks mate
|
|
I see that @oprypin published 1.2.2. Congrats! Does that mean that the project maintainership is sorted out? (Didn't see any further updates here) |
This comment was marked as disruptive content.
This comment was marked as disruptive content.
|
Oh, those were hidden by default. Thanks, and congrats! |
This comment was marked as disruptive content.
This comment was marked as disruptive content.
|
Done. You'll need to prompt me about the PyPI access some other time, can't do that right now. |
This comment was marked as disruptive content.
This comment was marked as disruptive content.
|
After some discussion it's been decided to try and onboard more plugin/extension authors on the team, see our announcement here: #3622. I just thought like sharing this here since it's relevant to the project's maintainership 🙂 |
Uh oh!
There was an error while loading. Please reload this page.
So, @waylan has said he'll be moving on from the project after the next release. It's not always a very rewarding position to be in and we've been fortunate to have had his stewardship for such a long time.
It's not really clear what's going to be best for the project next. From my personal perspective, a project at this stage generally needs someone who's willing to turn down feature requests and anything that brings additional complexity or release-risk, and focus on just keeping things well maintained. (But other folks might have differing opinions there.)
Having said that, I could see myself being more invested if there was enough drive to push a significant new version of MkDocs, which I have explored a little in the past. I'd be curious to gather folks' thoughts on what the most significant gaps in MkDocs are at the moment?
All reactions