In CloudStack (we use Github workflow now) only members can assign PRs and issues to users. Therefore, when an issue or PR is created it does not have an assignee. Then, when a contributor starts working on it, the community members (committer or PMC) will assign this contributor to the issue/PR. The member will also set the proper tags and milestone to the issue/PR.
I think in an open source community where everything is distributed, asynchronous and volunteer work we should leave the issues open to anyone until someone volunteers to work on it. Otherwise, we might face the risk of assigning issues to people, and they (the issues) never get resolved (for numerous reason that we do not need to get into details here). I also find issues without assignee more welcoming to contributors. I mean, if some issue has already an assignee I would think twice before starting to work on it; moreover, I would only reach the person if I really need the issue to be resolved, otherwise I would wait. On the other hand, if the issue has no assignee and I am interested to work on it, I start right away. To answer your questions: > can he or she assign it directly to maintainer? > I would rather open an issue/ticket and reach people in the mailing list; not asking for people to solve something for you, but rather discussing and trying to create a solution together with the community. Assigning things to people seems the role of a project manager that has some sort of power over the managed team. Speaking from experience I do not take it nicely when someone that uses the project I am a volunteer at (which I might now know ) “assigns work” to me. > Or contributor should always assign ticket to him or herself? > Leave tickets/issues open to people. Only assign them (tickets/issues) when someone has already started working on it (do you see the shift on workflow here? ). Then, you are not ordering, you are simply filling out some meta information regarding the person that has taken upon an issue. Is this regulated/recommended by the Apache policies? Not that I know of. On Tue, Jul 31, 2018 at 1:31 PM, Alexei Fedotov <alexei.fedo...@gmail.com> wrote: > IMHO good practice is that community is unaware of your company > policies. There is no gain in enforcing internal policies to external > community members. > > Adapt. ) > -- > Carry a towel > http://dataved.ru/ > +7 916 562 8095 > > [1] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ > [2] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings > [3] Start using Apache Openmeetings today, http://openmeetings.apache.org/ > > > On Tue, Jul 31, 2018 at 7:06 PM, Dmitriy Pavlov <dpavlov....@gmail.com> > wrote: > > Dear Mentors, > > > > I have a question that I have not yet found an answer to. Can community > > members assign tasks to other contributor in JIRA. I mean the case that > > someone wants a particular contributor to do a task, can he or she assign > > it directly to maintainer? > > > > Or contributor should always assign ticket to him or herself? > > > > Is this regulated/recommended by the Apache policies? Or it is given to > the > > community to decide. > > > > Thank you in advance. > > > > Sincerely, > > Dmitry Pavlov > > > > P.S. Discussion recently occurred at Apache Ignite community dev. List > > http://apache-ignite-developers.2346864.n4.nabble. > com/Fwd-jira-Assigned-IGNITE-9113-Allocate-memory-for-a- > data-region-when-first-cache-assigned-to-this-red-td33172.html > > > > And I always believed that it is always necessary that only community > > member can assign ticket to him or herself. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > > -- Rafael Weingärtner
