Wikidata talk:Requests for comment/Guidelines for RfC process

Current state: Discussion

Opening date of discussion: 18. August 2013 Closing date of discussion: 1. September 2013

(Proposal moved to the main page Filceolaire (talk) 12:37, 19 August 2013 (UTC))

Comments

• General comments:
  1. I see no reason to separate the decision part from the discussion part. If someone is really concerned about an RFC, how to phrase questions, and so forth, they should just add a new RFC for that or get some help from someone unofficially.
  2. I similarly see no reason to place a time limit on any part of an RFC. Some RFCs will take naturally less time, and others naturally more time, and some RFCs currently are more of "I want comments" and less of "We need to make a decision".
  3. I think this is something that definitely needs improvement (I started such a topic at Wikidata:Project_chat/Archive/2013/08#Policies, guidelines, and other-language participation). The first part would be to set up a bot for this of some sort to post to the project chats. I don't see a reason for adding a section to the community portal—it's a portal, not an all inclusive listing.
  4. Per bullets 1 and 2, I don't see this as necessary.
• Going from rather-loose process to this one is unnecessary. We don't need to make revolutionary change but rather incremental change. --Izno (talk) 17:10, 18 August 2013 (UTC)

  From the first idea until the final decision there are often a lot of changes because it is difficult to prepare from the first edition the final text which will be used as decision text. People have to be able to understand that the text is discussed or if the step of discussion is finished and only the decision has to be taken.

  Time limits are just a way to leave enough time to everyone to take part to the discussion and to the decision. This is really important as Wikidata is a small community and it is really difficult to say a decision taken by 10 persons represents the whole community. For the same reason, we need time in order to let enough time to the information to go to the different projects chats and to touch a larger set of contributors. Going faster just say that you don't take care of contributors which are not present every day in wikidata. Just have a look at the property proposals and at the last RfCs: they all need several weeks to reach a completion. So 6 weeks is not a too long time to get the acception or not of the community. And by putting time limits people are aware of official time and are not disturbing by RfC closed after 2-3 weeks and others after 6 months. If the time limits are too large you can propose to reduce them but definitively we need a time limit to avoid arbitrary decision of closing RfC.

  The community portal is common for all languages so each modification there can be seen by the different languages and translated. A bot is an idea but you have to be sure that you reach all languages. And depending how the different project chats are archived (some after one week) the post can disappear quickly. A announcement in the community portal is something that can be done by everybody. A bot should be maintained and here we are speaking about something for the future not only for the 2 next years. Snipre (talk) 17:46, 18 August 2013 (UTC)

  Maintaining a bot is far less work than managing announces day to day. It's just a few lines of code, an in the long term in the worst case we come back to manual processing for a short time while the bot is out. It's still far less work that starting to consider it should be a human task all the time :) TomT0m (talk) 18:00, 18 August 2013 (UTC)

• I think what would make more sense is to separate the proposition(s) parts from the discussion parts. Discussions can make consensual changes to the propositions emerge, and it seems great to make the proposition part clear enough so that a newcomer can easily get the ideas without having to face a possibly messy discussion. TomT0m (talk) 17:19, 18 August 2013 (UTC)

  That's what Snipre is proposing be the case, I think (even though he uses the term discussion and decision). --Izno (talk) 17:34, 18 August 2013 (UTC)

  Maybe, but as he did put everything on the discussion page it seems that either I did not understand whet he proposed or that this RfC does not follow itself :) TomT0m (talk) 17:37, 18 August 2013 (UTC)

  It is a test: this RfC is a test itself so if you prefer to have the text which is the results of the discusion in the main page, propose it and modify the RfC. That's the goal of the discussion: you are free now to change what you want. Snipre (talk) 17:46, 18 August 2013 (UTC)

• Great proposal, but what if, after six weeks, there is no comment or vote. Is the proposal accept or declined? - Sarilho1 (talk) 18:20, 18 August 2013 (UTC)
• There is no need to fix something that is not broken. The current process works perfectly fine. Just because you disagree with a close or one RfC is not structured in sections, is no reason at all to change an entire process which is fine. While I agree notification should be a part of it, only for requests which have major changes to Wikidata such as functionary policies. So this is RfC is part of the problem, split, unstructured requests based on the ideals of a single user. John F. Lewis (talk) 18:27, 18 August 2013 (UTC)

I disagree. I think the RFC process isn't working that well. Discussions ramble and we get no nearer to a decision, even after months. I think this proposal could help fix that.

I think all RFCs should be notified at each stage. The whole point of the RFC process is that it is for considering significant changes.

I don't think that RFCs based on the ideals of a single user are a problem. On the contrary, I think that RFCs are exactly the mechanism by which the ideas of a single user can be considered by the community. Filceolaire (talk) 12:53, 19 August 2013 (UTC)

• What would happen if, in the decision part, new discussions appear? Would these new suggestions be ignored? - Sarilho1 (talk) 20:57, 19 August 2013 (UTC)

Yes, in principal. New discussions should be phrased as a no vote since they are suggesting we not accept the current proposal and instead adopt a different proposal which has not been RFCed yet. If enough people vote against the current proposal and comment that they want to consider the new discussion then the proposer can withdraw the RFC and restart the discussion process from the beginning.

Words added to the project page proposal to reflect this. Filceolaire (talk) 19:34, 21 August 2013 (UTC)

New arrangement

I think this is a great idea but the draft proposal should be on the project page and the discussion of the proposal should be on the discussion page so I have boldly rearranged this RFC that way. What do you think? Filceolaire (talk) 12:37, 19 August 2013 (UTC)
section 4 changed to match See the diff here Filceolaire (talk) 12:43, 19 August 2013 (UTC)

I agree. It's easier to see where the current proposal is. The only problem is that people who want to discuss the proposal must be searching between to pages. (Not a huge problem) - Sarilho1 (talk) 20:51, 19 August 2013 (UTC)

One week is enough for discussion

For most RFCs the discussion dies in much less than a week. I think we should allow 1 week for discussion with a second week added if there are any discussions still ongoing after the first week.

Users should be notified 24 hours before the discussion ends so any last minute comments can be incorporated or so users can request a second week of discussion. Is it OK to ammend the proposal to add this? Filceolaire (talk) 19:27, 21 August 2013 (UTC)

What about one week after the last comment?--Micru (talk) 22:13, 21 August 2013 (UTC)

What is important is to fix the date of each step: you can fix a short duration at the begining and extand later but people have to know which is the deadline. Snipre (talk) 09:32, 22 August 2013 (UTC)

Look at the last RfCs: how many were closed in 2 or 3 weeks ? And the decision/vote is note the most time consuming part. Snipre (talk) 09:32, 22 August 2013 (UTC)

It seems odd to discuss for one week and then vote for 4 weeks? How about two weeks and two weeks? --  Docu  at 16:25, 31 August 2013 (UTC)

Changing the proposal process

How is the changing the proposal process going to work? Is anyone allowed to change it, and how is determined that the change is supported by a majority? --Sixsi6ma (talk) 13:33, 25 August 2013 (UTC)

Discuss the changes on the talk page then update the project page to reflect the discussion

or do the change on the project page and then describe the change on the talk page. Modify or undo if that is what the talk page discussion calls for.

Now go see if you can update the wording of the proposal to reflect our discussion here! Filceolaire (talk) 14:58, 26 August 2013 (UTC)

Translation

So far, most RfCs have only been in English, and mostly English speakers have been the ones to discuss and !vote on them, which leaves out non-English users.

Could we somehow incorporate translation into this proposal? We need to have the proposal page marked for translation, so that non-English users can read, discuss, and !vote on proposals. The Anonymouse (talk) 17:15, 31 August 2013 (UTC)

It is impossible to ensure that every comment, every modification is translated correctly in all languages: we don't have an army of translators working on demand. and as the number of contributors is quite small I don't expect to find enough contributors in each language to do that job.

Wikidata needs working language and this language is English because it is spoken by a majority of people at least as second language.

For me we can break partially these language walls by the announcements on the community protals or in the projects chats. Then some discussions can be done in each project chat in the appropriate language. I think we have to let each project chats managing the information spreading and the report of comments. This is not the optimal solution but we can't offer something better because we don't have the ressources. So my proposition is 1) we inform each project chat of the different parts of the current RfCs and 2) they have to find an internal solution for their non English speakers. Snipre (talk) 09:28, 1 September 2013 (UTC)

I meant just translate the proposals, not the comments, since that obviously is not feasible. Announcing at the community portals and project chats is definitely a good idea, though. The Anonymouse (talk) 20:27, 1 September 2013 (UTC)

It would be possible to translate just the proposal, but ensuring that the translate tags only include the proposal part and not the discussion/voting. Ajraddatz (Talk) 22:12, 1 September 2013 (UTC)

When I see the time needed to translate guidelines I am a little afraid that the period between the discusion and the decision part will be long. Snipre (talk) 23:04, 1 September 2013 (UTC)

This should encourage the initiator to define its proposal in a short and clear manner :) I strongly  Support with the idea of proposal translation (with an aid of translation extension). Infovarius (talk) 12:33, 27 September 2013 (UTC)

Comments

 Comment One of the most important points isn't covered by this RfC: Are the conclusion of an RfC just a recommendation or is the conclusion a commitment? Or, should a RfC decide itself the conclusion is mandatory or not. --Nightwish62 (talk) 20:22, 4 September 2013 (UTC)

This is not covered so there is no decision on that topic. And the proposal explains clearly this point of view: the discussion part has to define the questions, the framework and the application of the RfC. A RfC can be a simple discussion without decision, a sondage or a mandatory application. Again, this RfC doesn't deal with the content of RfC, only the form of the RfC is discussed. Then the proposal is defined as guideline: this is not a mandatory text, but we will need a good reason to use another form, if this RfC is accepted. Snipre (talk) 21:47, 4 September 2013 (UTC)

Comments on discussions in the decision part

RfCs and models

Which property to use in each case is one of the crutial part in Wikidata. I think we should have an efficient and dedicated process for that that is distinct from general RfCs (who should more in my opinion dedicated to other discussions, such that an agreement to this process. We can't have the same process for decisions we have to get all the time for all kind of types of items and domains than for general discussions on the project. TomT0m (talk) 09:09, 25 September 2013 (UTC)

I don't think these should be dealt with in RFCs. I think they should be developed in permanent pages - perhaps attached to the task forces. Filceolaire (talk) 23:40, 25 September 2013 (UTC)