Process managers - triaging issues, ensuring the flow is good.
Decision makers - making sure enhancements and features are designed well and in line with Yii values.
Bug hunters - verifying bug reports.
Contributors - working on bugs verified and enhancements/issues by the specifications agreed on during discussions.
Code reviewers - making sure code is good before merging it.
I’ve added a few more statuses and removed some so contributors may quickly select issues that correspond to their roles. As a bonus we may implement a simple analytics using github APIs to know if there’s lack of free hands with a certain role and request community for help in that area.
It is good to review process and see if we can improve it. Having some rules to go by would improve overall quality and workflow I think.
About the schema.
Looks really good to me, however you skipped PRs for documentation and translation changes. If we publish this somewhere officially, we should either add this or state clearly that for those changes this workflow does not apply.
About contributor roles.
It is good to rely on labels. Often when we get asked by people how they could help, it is hard to point them to something. Having these groups we can say which issues are good for what kind of contribution.
I would not assign these roles directly to people, having the labels people can decide for themself which group they want to belong to, even working in multiple groups. There does not need to be fixed assignmetns.
There are many aspects to deep in, but it is a good starting point.
Let’s get to it.
Your scheme is good to handle incoming issue, I have some comments on each:
“Process managers”. It’s clear, ok. It would be good if we started to identify people who does what. This ensures that more people don’t work on the same things without know it.
“Decision makers - making sure enhancements and features are designed well and in line with Yii values.”. I asked many times to have a kind of guideline (or patterns) to identify and solve recurrent problems and cases. I think that having clear guidelines can be considered a value, because it avoids that different developers use different programming patterns. Otherwise often we talk about the same thing.
Bug hunters. This is a my dream for Yii 3 :). Developers should give full weight to write tests, because in my mind tests are the first place where errors are catched, but Yii (and also other frameworks) does not give much importance to speed up writing the tests. If we created a template or kind of accelerator to write tests, everybody would not consider them a loss of time.
Contributors. As the first point, we need at least to know 2 things: roadmap, what are the things to do, and who are doing what. Now nobody knows what are the progress of Yii 3.
Code reviewers: At this point having guidelines (point 2) would give to every reviewers the tools to check if code is good from Yii point of view and not from his point of view.
To sum up:
A) Start to apply a process to manage the issues (your proposal is good);
B) Write a clear and reasonable roadmap, identifying every aspect of Yii 3 development to do;
C) Identify people or group people that do the things;
D) Start to write all Yii values and guidelines that help to solve well known cases in Yii style (useful for code reviewers);
E) Enforce and speed up to write tests (useful for bug hunters);
I’d start with these 5 points that are simple, clear and not abstract things to do (IMHO).
I’m feeling that it will not fix the main issue - there is not enough manpower to triage/verify/fix/implement all bug reports and feature requests. Still, all new issues are planned to next milestone - 2.0.17 has already over 200 tasks assigned. Most of them do not have a person who wants to implement/fix them. The result is easy to predict - release is delayed because nobody wants to do planned tasks. In the meantime, new issues pop up and interested people implement them. In the end, we have a release like 2.0.16 - enormous and delayed (almost one year of development), but still not cover all planned tasks.
I suggest to not plan non-critical tasks to milestones. Just use labels to keep tasks in buckets and assign them to milestone only when someone picks them and implement. It will not help with lack of manpower, but at least we may have some sane release cycle (you can release at any moment, you don’t need to way 6 months till 200 planned task will be fixed).
Yes. That is one my next steps. Finish overall re-planning. There’s a need for it because more PSRs were released and existing PSRs were not implemented correctly in fact.
Great idea. Added to my todo. Thanks!
I’m actually not sure about that. People are often asking me “how could I help Yii” and sending them to check random issues doesn’t work well. So we may see improvement in this area.
That is a good suggestion. Need to think about it but I see no cons for now.
What is missing is label and cleanup policy for low-quality bug reports and niche feature requests. There are many bug reports that are hard to verify, especially that most of them are incorrect and they’re usually configuration errors. There could be a label for such reports (we actually may use to verify) and we could close them after ~1 year if nobody confirms them. Same for feature requests - there are many ideas that would make sense to implement and there are no objections, but nobody wants to implement them, which usually means that nobody really needs them. yii2 tracker is full of staled and abandoned issues, some policy to close old issues may help a lot in keeping issues list manageable.
me: Hi samdark I want to contribute to Yii2
samdark: Great. Pick #17174 complete it with test & send pr. By what time you will send pr ?
me: ok, by 06 Mar
samdark: done
At this point some labels & comment combination should clearly state that @sohelahmed7 is working on this issue. He will complete it by 6th Mar
So no one else will start working on it
Same way PR review process is carried out
Why name and time is necessary? No two contributor work on the same issue at the same time
I would add a feature when decision considers right only after a few reviews. I remember the situations when initial decisions were wrong and it caused many problems in the future. For protection purposes from such situations we can ask for a few approves on important levels. But on other side, I don’t like to wait too long.
We don’t really have this problem at the moment. And I’m afraid that setting a due date will end up generating “stress” more than anything else. And you’ll end up with a bunch of issues assigned, overdue, and busy assignees not answering anymore, then not contributing anymore to other stuff as they would feel that they let us down the first time.
I deal with due dates at work, I don’t want to deal with them for open source, aside from releases dates, or when doing a collective effort with the rest of the team.
2.0.16 was stuck until we moved almost everything to 2.0.17, and during that process, I’ve seen issues that were pushed from milestone to milestone for years now.
As we’re in maintenance mode only for yii2, I think that we should un-milestone everything, and have way more frequent bug fix releases.
I’m feeling that it will not fix the main issue - there is not enough manpower to triage/verify/fix/implement all bug reports and feature requests. Still, all new issues are planned to next milestone - 2.0.17 has already over 200 tasks assigned. Most of them do not have a person who wants to implement/fix them. The result is easy to predict - release is delayed because nobody wants to do planned tasks. In the meantime, new issues pop up and interested people implement them. In the end, we have a release like 2.0.16 - enormous and delayed (almost one year of development), but still not cover all planned tasks.
I suggest to not plan non-critical tasks to milestones. Just use labels to keep tasks in buckets and assign them to milestone only when someone picks them and implement. It will not help with lack of manpower, but at least we may have some sane release cycle (you can release at any moment, you don’t need to way 6 months till 200 planned task will be fixed).
Your workflow schema is good, but it’s suitable when there are a lot of people in the project. Unfortunately, we have a different situation now. We have very few resources.
Therefore, we should plan less, but release more often.
Yes that is valid point
I agree there should be no stree on contributor because of due date
In order to avoid that we can encourage them that you can freely extend due date anytime we want + you are the owner of that particular task/issue + you don’t have to give any justification if you extend date
End date is important when contributor (who self assigned the issue) abandon the issue (ie no pr after enought time of end date) and then core contributor can self assign & complete the issue
