I agree that we should try to keep the number of issues without a pending PR assigned to each person down.
Given that different people have different amounts of time to dedicate to the project, it seems fine to me that someone is assigned an issue even if they are working on it off and on. If an issue appears inactive and someone wants to take over or just contribute, they can always post a comment to the issue to see if the assignee is still working on it or willing to collaborate. In that case if the assignee doesn't respond within a reasonable timeframe it's probably fine for someone else to give solving the issue a shot. It's obviously ideal when the assignee for a large issue communicates progress occasionally, and I feel like people do that pretty often either via posts to issues or WIP PRs in case there's a need for discussion. With regard to the idea of competitive work, I think in general it's probably better if we can avoid redundant work where multiple people are working on the same thing at the same time. I don't like the idea of leaving an issue that is being worked on unassigned if we can avoid it. I think the best way to avoid duplicate efforts is to make sure that we keep JIRA issues up to date so it's visible if an issue is being worked on. By "up to date" I mean both who is working on the issue, but also what the problem description or idea for solution is. Sometimes issues change scope as people work on a fix, but it's hard to avoid overlapping work if the issue says e.g. "Upgrade Mockito", but the assignee is actually working on "Upgrade Mockito and fix storm-webapp tests on Windows". It's my impression that people are already pretty good about keeping issues updated though. People who contribute often are hopefully subscribing to storm-issues, so it should be pretty easy to stay up to date on what people are doing by following that list. 2017-08-31 1:58 GMT+02:00 Jungtaek Lim <[email protected]>: > Hi devs, > > I feel I have been seeing "no timeframe" from Storm project (sadly I also > had to use the word to explain the plan on Storm 2.0.0) at least starting > in this year so I think we need to define what exactly the "no timeframe" > is, to avoid the word to become a major issue for the project. > > Personally, unless any pull requests or any shared plans or any transparent > progress are provided, I'd rather treat "no timeframe" as "ASAP", not > "eventually". > (Sadly, again I have to admit that I didn't use the word with such meaning > to explain the plan on Storm 2.0.0. It was just exactly same as what "no > timeframe" originally means though I have in mind to make it being released > ASAP.) > > Definitely it doesn't mean we should spend all their time to do the work. > It means we should be open to explain about the (tentative) plan on their > assigned issues and also open to explain the progress of the work > transparently. This implicitly means that we are expected to be assignee on > the issue only if we can start making a progress now or in short period, > and open to someone taking over the issue if we couldn't make the progress > for a long time. > (It would be much nicer if we could even step down from assignee ourselves > before someone asking to take over.) > > According to my definition above, being assignee to multiple open issues > are not ideal, unless they're coupled. Maybe it is possible and valid to be > assigned to several issues (may less than 5?) at once but not ideal to be > assigned more than 10 even though issues are trivial. If someone is > assigned to multiple open issues, they should be open to talk about > priority of issues (simply which thing(s) to do first). > > We all are distributed and consists of multiple teams and also individuals. > Sure we don't have stand-up like thing, and we don't sync up explicitly. We > should consider about how we work practically in this nature, and I think > being open and transparent is the key to success. > > Would like to hear your opinions about this. > > Thanks, > Jungtaek Lim (HeartSaVioR) > > ps. Btw, my 2 cents, I don't mind allowing positive competitions in this > project, like having no assignee and first (or better) implementor becoming > an assignee. (If there's design doc or so, writer of design doc should > become assignee to get any kinds of credit.) I feel we worked like this > before. >
