Dear Mentors, Thank you so much for your comments on this topic. I feel in completely the same way.
I will continue to learn the Apache Way, and I hope I would be able to help to other communities. Sincerely, Dmitriy Pavlov вт, 31 июл. 2018 г. в 20:09, Rafael Weingärtner <[email protected] >: > 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 <[email protected]> > 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 <+7%20916%20562-80-95> > > > > [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 <[email protected]> > > 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > Rafael Weingärtner >
