Closed pmargreff closed 7 years ago
@pmargreff
1) Yeah, I agree, but I think that gitter works as expected. 2,3) Sadly, this is out of the scope some active contributors like @tomscholz @DanielRuf, we are claiming for that too. 4) yeah, the bug fixes shouldn't wait.... @acburst
1) I though about a discord server instead of gitter : multi channel chat room could be reeaaaally usefull. Add a git bot and it'll become a better gitter than ever
2) Well, i think 1) would be helpfull to role management and it will became easier to "find", "hire" & "fire" contributors.
3) @fega +1, bug fix shouldn't wait, I remember some bug had multiple PR in the past ... shouldn't happen. And again, 1) could easily resolve this
4) I think some "auto-release" could be great and some repo are actually doing this.
Here an organisation example that can be based on discord server "role management" :
Non-blocking bug and fixing 'style' are quite boring because you don't really need to test : most of the time wysiwyg. little contributors are in charge of these kind of tasks. PR are validate by people, as soon as 10 approval, auto merge in branch "little-patch"
Blocking bug and fixing 'process' are more important and need more attention, but you can apply the same principle : big contributors are in charge of these tasks PR are validate by people, as soon as 20 approval, auto merge in branch "big-patch"
New features are even more important : we need an approval from lower role+community+valid material design but, once again, same principle : feature contributors are in charge of these tasks PR are validate by people, as soon as 30 approval, auto merge in branch "feature-patch"
Most important role, without them, nothing happen, people in here are dedicated heart & blood to these project (well ... they don't do a lot but without them project is dying) : watchers contributors add label to issues and PR so upper role can do their jobs ...
Well, we still need human validation : author & merger contributors check branch and merge them every X days
"little-patch" -> 10 approval -> weekly "big-patch" -> 20 approval -> weekly "feature-patch" -> 30 approval -> monthly
Some will say "well, that escalated quickly, it's overkill for this repo" Well, it's not. People & their project fly away when they see our project management... as soon as this will be in place, contributors will crop up all over the place.
multi channel chat room Gitter also supports multiple channels. Administrators have to create them.
Keep in mind that there are very few contributors and this whole structure would require huge efforts from the whole community.
Nonetheless great ideas but this will likely not happen in the near future.
What we need are mentors, meetups, more great webcasts, courses and mainly developers pushing the project forward.
@DanielRuf I didn't know about gitter and multiple channels, could work too anyway :+1:
Closed due inactivity. Feel free to reopen it, if it's still necessary.
Description
Hey there, first of all, I want to say my appreciation for the project, I'm a heavy user from Materialize since the firsts releases. But I want to give you some my worries about the project progress. I start to think about that after I saw this great feedback from @yanickrochon, I don't agree with "the lack of interest", we need to consider all people have a life out of here, but the other points are very meaning.
So let's start with the chat, I know it's a long discussion but, the project chat room is a confusion and the question is barely answered there, the same for the maintainers, they didn't show off so often to interact. You'll never make everybody happy with your decision, but have channels to a deep discussion about FEATURES, BUGS, IDEAS, DOCUMENTATION AND QUESTIONS look much better for the organization in my point of view, and I can find any reason to don't migrate. If you worry about loose some contributors you could maintain the old channel open parallel with the new one, to test which works better. You have a lot of options here: Rocket.chat, Slack, Discourse, etc ...
After I don't know about the workflow for the project, yeah, I know you have a contribuitor guide and it's awesome and is very nice how you focus on guiding any contributor to test too. But, you have a bunch of PR opened and it has two means, first, you have a lot of people with the desire for contribute, two: you have a bottleneck to answer the PR. But it doesn't look clear to me the next goals, and the main priorities of the project.
Probably the creators could be too busy (college, work, other projects ...) to give a better attention to the project, but once you have something like 26k or more project dependent on you, I think the things should be agiler (not in the agile sense, but in feedback deeper in your answers). Look at your contributors' number, the code is cheap, you shouldn't worry about the code if you haven't any available time, maybe focus on guide the contributors with a good PR feedback, bug fixes, and new functionalities could be a better way to more constant and substantial releases. And in the last case, if you have the actual time to continue this, should be nice start search someone with free time to make more substantial stuff.
The last point is your periodicity for the deliveries, I know it isn't a great deal make a lot of releases with no substantial stuff, but try to define some dates could help to make more deliveries with features and/or bug fixes.
Please, don't get this message wrong, the only reason about writing that it's because I like too much the project and it would be a horrible thing see it die because of operational fails.
Best regards.