Re: [JBoss-dev] Assigning JIRA tasks to non-committers

[Ovidiu Feodorov]

Scott M Stark wrote: The Community Task was instead of creating a new group. If there is a non-committer group it’s a mute point. For the following I don’t see the point of a contributor assignment as the task should not even be created until the issue is to the point of the artifact being ready:   -          proof of concept. This has to be discussed in the design forum so I don’t see why a jira issue is needed in addition. Because there is a lot of noise in the forums. I have limited control over how discussion threads are being created and how they evolve. A forum thread is an open conversation that hopefully helps define and distill a very clear set of issues that need to be executed. Ex: proof of concept that must do this and that. In my opinion, a design forum thread must end with one (or more) JIRA issues or be wiped out as irrelevant. I would like to be able to control more tightly the tasks that are being generated this way, and associate names with them. (by the way, associated a JIRA task with a trhead this is a forum feature I suggested long ago. JIRA can point to a thread, why not a design thread point to a JIRA issue, but now I am diverging).  To conclude the "proof of concept" point, there is an issue (the JIRA task), a deliverable (the prototype or some amount of functionality that has to be implemented) and a person that does the work and doesn't necessarily have to be a contributor. -          Testing. What functionality exists for which no testcase exists? If you are just wanting to punt the work of testcase to the community, ok to the extent that this does not mean a test is not written. This is border line broken development in that untested features are being released. Correct. However, I can create a JIRA task for a testcase I thought about but I didn't not implement yet. Another type of testing JIRA tasks I can think of "test X feature on the Y platform while interoperating with the Z thirdparty entity and generate a configuration file tuned for X/Y/Z that will be added to the pre-packaged set of alternate configuration files. The task and the deliverable are clearly defined, and they can be executed by a non-committer. -          Provide code examples. Unless this is making it into the project docbook, what use is it? It’s just going to be out of date as time goes by. Messaging comes with a set of "examples", each of them containing a README file and a small number of classes that demonstrate a simple feature: sending/receiving a message to a queue, sending/receiving a message to a topic, deploying an MDB, etc. These examples serve two purposes: give a novice user a starting point with the and serve as a second layer of integration tests, as they can be automated and they are run and must pass on each release. Each "example" has a standard format, and I would be happy to get some of these from the community to include them with the release. Since there are contributors asking "how can I start contributing", I would put a set of this kind of tasks out, ready and up for grabs. They can be assigned immediately and do not imply a significant learning curve to produce. No CVS access is required and there is a very well defined deliverable produced by the task.   For a patch, I can see assigning it to someone just so that there is a notion of ownership to prevent duplicate work. Same for a wiki page or article. A patch (in this case is a JIRA "Bug" that sits out there in the open) can be assigned to a non-committer and then be applied to the code base.   A more basic jira question is, can jira be setup such that a contributor can assign a task to anyone, but only the contributors show up in the drop down list? If that is allowed let’s set this up and forget the community task and separate contributor group as the distinction and maintenance of the group is questionable to me. The maintentance of the group is the biggest issue, I agree. I don't know what this implies, but if it's a lot of trouble, I guess we can live without it .... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ovidiu Feodorov Sent: Thursday, December 29, 2005 10:35 AM To: JBoss Development Subject: [JBoss-dev] Assigning JIRA tasks to non-committers   Sometimes it is probably appropriate to assign a JIRA task to somebody who is not a CVS committer. These are cases in which I find this useful: - Creating a proof of concept or a prototype that most likely won't make it into the main code base in its actual form. - Providing patches that will be ultimately applied by a committer to the code base - Testing functionality and specific configurations. - Provide code examples - Write a wiki documentation page or other type of article None of these tasks require their assignee to have committer access since they don't imply CVS write access. However they would help a project lead to keep track of who is doing what and administer more easily work that is done by non-JBoss volunteers. The current JIRA setup doesn't allow this. In order to enable it, we will need to add a new group to JIRA ("Contributor" or similar) and probably a new task type "Community Task" (Scott's idea).  Personally I don't see the usefulness of the last one, I think the existing "Task" is sufficient. Following the same logic, a "Contributor" can report an (existing type) "Bug" or can suggest an (existing type) "Feature Request" and he can be also assigned to it, pending a patch submission. The patch will be be applied to CVS by a committer, usually the one who assigned the task to the contributor. A project lead should be able to include an user in the project's "Contributor" group. Again, this DOES NOT implies that the user will be granted CVS access. This arrangement could also be a good motivator for volunteers, as they see their contributions publicly recognized and documented. Being a "Contributor" should be prerequisite of becoming a "Committer". Please let me know if you find this useful. Regards, Ovidiu