Proposal to make a page with some quick reference table for marking Issues:

Issue activity

Status Doc Team - Newbies Questions
active That's clear
fixed

Why should this type of issue stay 2 weeks in Documentation Issues list, before marked "Closed" ?

Could we short the period it get closed automatically?
Can a Team member close the issue if it's checked and ready to be close or should wait 2 week before it's automatically closed?

duplicate What is the best handling with "Duplicate" content and or added comments even if it's being tagged as "Duplicate?
postponed

When it's "postponed" could we make a minimum "Period of Time" that after this became automatically an "Active" Issue ? Would be useful in seeing that the "Issue" will be taken in consideration or it's ignored for to much time that it could be "Closed" for "Unmaintained" or "Irrilevant"?

won't fix How long a "Won't fix" will stay in list ? Or it dissappears automaticly from the list yet?
by design Could You please define me exactly what this does mean?
closed That's clear
patch (code needs review) Could we define what is the difference with "patch (Code needs work) ?
patch (code needs work) Could we define what is the difference with "patch (Code needs review) ?
patch (reviewed & tested by the community) When is a "Patch" really (reviewed & tested by the community)?
active (needs more info) Could You please define me exactly what this does mean?

Please add your Opinions, Suggestions, best short answers to fill the Table.
Disregard, Support etc.

p.S.

In favor (ie Ok, I'm with it) comments should also suggest the best place for this Type oc Content.
Of course I would expand also to contain a table for: see Addition of section with "Issue report Component" - description.

I would first build and publish here a "Draft" so to give anyone the possibility to correct and refine.

Collaboration is very much appreciate. ;-)
Thanks

Comments

webernet’s picture

webernet commented
Status: Active » Closed (duplicate)

http://drupal.org/node/156119

Wolfflow’s picture

Wolfflow commented

Thanks @webernet

Just want to add that those explanations in the link you provide refer mainly the Development Team.
In fact it's under Developing for Drupal

I think this differ somehow from the work and support type the Documentation Team and all new joined Member have to learn to deal with.

This is why I submitted question under the "Doc Team - Newbies Questions".

It would be very much appreciate if we can strength our efforts and build a reference for.

Thanks

Wolfflow’s picture

Wolfflow commented
Status: Closed (duplicate) » Postponed (maintainer needs more info)

Therefor this is not a Duplicate but "needs to be reviewed!

vm’s picture

vm commented

Issues are normally worked on by the development team which is why I believe webernet linked to them. There would be no difference which team was working in the issue queue, the rules would be the same regardless.

_________________________________________________

Fixed = 2 weeks allows other users who run across the issue to chime in, or the original poster to report back that the problem wasn't fixed in a follow up. It should stay so others can quickly see the Q & A and may be able to help clairify the answer given.

won't fix = the developer decides that they won't add a feature or some other such task. I don't believe these should "disappear". When things disappear it forces users to ask the same questions over and over again. Drupal should remain open and transparent. As such things should never just "disappear" or be removed.

by design = works the way the module developer intended. There are occasions where a new user to a module reports a bug because the module doesn't do "exactly" what that user wants. In this case a feature request should be filed rather then a bug report. In other cases, the a modules developer may have specifically left a feature out of his/her module because another module in the communities handles that functionality.

patch (reviewed & tested by the community) = when others inside the community apply the patch and deem it working as expected and properly.

patch needs review = people need to review the patch and report working or not working

patch needs work = the patch is in some way, broken, doesn't comform to coding standards or has some other problem that needs addresses that was foudn during the review.

active (needs more info) = someone looked at the issue and that person requires more informtion from the bug reporter.

__________________________________________________________

I understand you are viewing the documentation team issue queue, but it is important to keep in mind that the issue queue's are more often used by project module developers to report bugs, file support requests and other project developer type issues.

Wolfflow’s picture

Wolfflow commented

@VeryMisunderstood

I appreciate your point of view, but I think we should a bit divide and organize better the way the different working groups on Drupal.org do achieve to let retrieve informations to the target group of interest in supporting our work here.

I know the they are a lot of members of the "Doc-Team" that also are part of the "Develop-Team" and viceversa, But I'm sure that even if we All deal with "Drupal" which is our common interest it's obvious that the work and support differ, so that's because we started to build Documentation sprints for better docs and to grow the team and there is a Getting involved handbook section.

You sure know about New "Getting Involved" docs handbook and that the About Drupal documentation will be the resource for information for all Visitors and new Members that want to contribute and help out on Drupal.org.

So if you mind I just do provide my feedback as a Drupal.org Visitors from the point of view of a Beginner that want to find clear, accurate and simple information if I should contribute to the Community.

:-)

vm’s picture

vm commented

I don't believe what you ask is possible at moment. I could be wrong. dww would probably be the best person to answer the questions as he's the maintainer of the project.module if I remember correctly.

I'm certainly not trying to snipe your ideas.

Wolfflow’s picture

Wolfflow commented

Thanks @VeryMisunderstood -

I appreciate your advice to refer to @dww but as I care for providing a good support to all newbies and no-native english visitors on Drupal.org and as Site Maintainer I try to help in focusing on The importance of Terminology and have already add a small reference list to the list on Common expressions & acronyms used on D.O. a small summary of Status levels of Issues.

If this should be not wished every one of the Site maintainers can disregard for and subsequently vote for deleting it from the page.

I Continue to ask for support on clearing this out. Maybe I would be misunderstood so I again explain that for me it's important just to have a page to describe the different meaning to apply on the Status levels of Issues and not to change the Drupal.project module.

I hope this clear a bit more my motivations.

Thanks

add1sun’s picture

add1sun commented
Title: Proposal for a "ISSUE mark descriptions": explanations Table for each mark type » Update status level of issues page
Component: New documentation » Correction/Clarification

Well, http://drupal.org/node/156119 is going to moved out from under the "Dev handbook" in the reorg that comes with the Getting involved book. There is a whole section just for explaining the issue queue (#240213: Getting Involved: Issue queue pages need work) so this page will move there and be the basic guidelines for everyone.

@wolfflow, in your questions in the table you created about changing the *behavior* of the various statuses you are, in fact, asking for changes to project module itself. We can document the issue statuses here, but this is not the place to request changes to the issue queue functionality.

I'm changing the title of this issue to make it clear that the task at hand here is to simply update http://drupal.org/node/156119 for clarification if things are not clear and incorporate some of the "special" ways that the docs team interprets some statuses due to the different nature of the docs queue. Please review that page and ask for specific clarifications that need to be made to that page. Thanks!

Wolfflow’s picture

Wolfflow commented

Thanks @add1sun. Again it's hard for me not to make me misunderstanding. I see yet that it look like you right interpreted my issue. Again my intention was and is only to build an "Informative Page" in form as a Table that contains
the different definitions and explanations to the stuff.

This is only a draft. I know I should take english writing course !!! ;-)

Wolfflow’s picture

Wolfflow commented

As of #4 from @add1sun
to thread Addition of section with "Issue report Component" - descriptions

Every ones is invited to propose suggestions, drafts etc. to this page.
Please post here your contributions.

Thanks

Wolfflow’s picture

Wolfflow commented
Status: Postponed (maintainer needs more info) » Fixed

Meanwhile the Issue Submit Form - Description Table is published but still incomplete.

If someone can have a look at (English grammar, Definition of some fields, missing links) that will be great.
So I close this Issue and of course if needed everyone can reopen.

Wolfflow’s picture

Wolfflow commented
Status: Fixed » Needs review

Changed for getting a review. Help very much appreciate. Thanks

Wolfflow’s picture

Wolfflow commented
Status: Needs review » Reviewed & tested by the community

Ok I have add the last incomplete definitions and description for the informative Issue Table I would really appreciate if
someone got a bit of time to review and tag this as "Complete".

Thanks

add1sun’s picture

add1sun commented
Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.