I think it would be a good idea if you would add a few more Collaborator or Members or whatever github supports as rights.
This would make the project go faster and probably smoother.
Also this would take away work from @Chocobozzz and @rigelk .
Especially it would eliminate the single point of failure or whatever you want to call it.
As we see at the moment, @Chocobozzz is away and @rigelk seems to not have that much time.
The project almost seems dead or at least not very active.
I think it would be nice if someone else could help label issues, review PRs, maybe merge PRs, ...
For me, it seems that the project got bigger: now over 250 issues, and 15+ open PRs. Maybe more help is needed/appreciated.
I suggest @Nutomic @scanlime @Jorropo and some others that seem to know much about this project and also contributed much.
just my opinion :)
what do you thing about this?
Why not :slightly_smiling_face: But I have doubts it will solve all the problems you mention.
FYI, I'm currently not merging PRs because I am waiting for feedback from @Chocobozzz - I'm still not confident enough about some parts of the code, or simply for architectural choices.
While labeling issues is certainly something that could be helped with, I don't see how appointing new members would help review PRs (something that can already be done without a special status).
maybe it is help enough if some of the mentioned and/or more experienced contributors, try to review some PRs and you can sooner or later trust their judgment and only take a quick look and then merge
Something review by 3 people (having the same opinion of course) is better than just from one person
My two cents; happy to help out to the extent I can, but I feel like my personal limits here aren't related to not having commit access. If I had ability to tag bugs (and we agree on how that process works) perhaps I could help out more with organizing the bug tracker, but mostly I think the limitations I'm aware of are related to the number of people who have knowledge of the architecture and what directions to go in with the project. It'll be hard to figure out how to add giant new features like livestreaming without discussion that includes @Chocobozzz, for example. That said... there's a ton of work to do here that isn't really limited by access at all and likely have implementations that don't raise a ton of widespread architectural questions in the process. For example, bug fixes, new moderation features, a lot of this just needs people to do the work. Access might help organize that work somewhat, but I think we also just need more hands on deck or whatever when it comes to writing and testing patches.
@scanlime I think you point something important. We maybe need to write somewhere what must be the direction of PeerTube. What are the priorities? What will never be implemented? What need a lot of discussions?
Maybe it's time, for the project, to find a way to organize who fits its growing nature.
Something like we can see with Rust, per exemple? With a roadmap based on the feedback of users, defining priorities for the short and medium terms.
I don't tell we should copy them on every points but it could be an inspiration on the way to organize how to contribute.
Anyway, I think it's good to discuss about what exactly we, as PeerTube users, contributors, developers, etc, want PeerTube to be. We have few ideas because of the crowdfunding campaign about which features are planned for PeerTube but some ethicals points are still unclear. How to manage advertisements or remuneration (via extensions, I think I've read somewhere)? Should we implement ads? How should extensions work?
There are a lot of things who are maybe in the mind of some people but we can't know what are their plans actually.
@Booteille I really like the idea of Rust's call for blog posts. Might draft a similar call for december, with topic suggestions from the recent/favored issues and known needs like moderation and documentation.
Note that a few of ideas have been discussed on Mastodon and Framacolibri but not always translated to english or linked to the GitHub tracker too. Taking a moment to gather them might help too.
@Booteille I really like the idea of Rust's call for blog posts. Might draft a similar call for december, with topic suggestions from the recent/favored issues and known needs like moderation and documentation.
I like it too. It helps a lot to quickly know what's happening on the project.
Note that a few of ideas have been discussed on Mastodon and Framacolibri but not always translated to english or linked to the GitHub tracker too. Taking a moment to gather them might help too.
Yeah. That's what I thought. But I definitely think this is worth it to aggregate informations somewhere once, then to fill it with each new information.
I think we are good regarding issue labels. Everybody can review/comment any PR/issues, but merging PR requires a lot of PeerTube code knowledge. But if you want to become a PeerTube collaborator, you can reach me by email, in my Github profile.
Most helpful comment
My two cents; happy to help out to the extent I can, but I feel like my personal limits here aren't related to not having commit access. If I had ability to tag bugs (and we agree on how that process works) perhaps I could help out more with organizing the bug tracker, but mostly I think the limitations I'm aware of are related to the number of people who have knowledge of the architecture and what directions to go in with the project. It'll be hard to figure out how to add giant new features like livestreaming without discussion that includes @Chocobozzz, for example. That said... there's a ton of work to do here that isn't really limited by access at all and likely have implementations that don't raise a ton of widespread architectural questions in the process. For example, bug fixes, new moderation features, a lot of this just needs people to do the work. Access might help organize that work somewhat, but I think we also just need more hands on deck or whatever when it comes to writing and testing patches.