Hola, Replysixty, ¡ bienvenido a Wikipedia! Gracias por tus aportes . Espero que te guste el lugar y decidas quedarte. Aquí tienes algunas páginas que te pueden resultar útiles:
Espero que disfrutes editando aquí y siendo un wikipedista . Por favor, firma tus mensajes en las páginas de discusión usando cuatro tildes (~~~~); esto insertará automáticamente tu nombre de usuario y la fecha. Si necesitas ayuda, consulta Wikipedia:Preguntas , pregúntame en mi página de discusión o formula tu pregunta y luego colócala antes de la pregunta en tu página de discusión. ¡De nuevo, bienvenido! ¡Y gracias por las fotos! shoeofdeath 23:33, 9 de noviembre de 2007 (UTC) [ responder ]{{helpme}}
Imágenes de la huelga de WGA
Gracias por todas las imágenes de las huelgas del WGA. Dado que todas son PD, es posible que desees subirlas a Commons en lugar de a Wikipedia. Esto las hace disponibles para Wikipedias en otros idiomas sin necesidad de volver a subirlas. Ya he subido algunas de tus imágenes a Commons (ver [1]). Agregarlas a artículos en Wikipedia es exactamente lo mismo (es decir, [[Image:Imagename.ext|...]]). Evil Monkey - Hola 23:32, 10 de noviembre de 2007 (UTC) [ responder ]
En serio, muchas gracias por las imágenes. Avísame si necesitas ayuda. Miranda 01:05, 12 de noviembre de 2007 (UTC) [ responder ]
Cuida tu lenguaje
Deberías cuidar tu lenguaje, de lo contrario informaré a las autoridades. (: - Yours jealous, Superior (discusión) 02:12 18 nov 2007 (UTC) [ responder ]
Huelga de la WGA
¡Qué audacia la de eliminar la sección de actores de la página del WGA! ¡Ya era hora de hacer algo, gran trabajo! Snowfire51 ( discusión ) 00:28 2 ene 2008 (UTC) [ responder ]
Imagen: Jeff Garlin y otros en el rally WGA.jpg Actualización
Me gustaría preguntarle si estaría de acuerdo con que subiera una versión más reciente de la imagen a la que se hace referencia en el título de esta discusión. Con Adobe Photoshop Elements , aclaré las sombras que se ven en la imagen (principalmente las de Jeff Garlin ). Polarbear97 ( discusión ) 22:35 12 ene 2008 (UTC) [ responder ]
He notado que has cambiado el tamaño de la imagen de este artículo a un tamaño forzado de 300 px. He revertido ese cambio, así como también he reemplazado el código br-clear para que las referencias aparezcan correctamente en la página independientemente del ancho y la resolución del monitor. Deja este cambio en su lugar para cumplir con el MoS por Displayed Image Size . Esto evita que la imagen anule las configuraciones de preferencias individuales. -- Faith ( discusión ) 18:03, 21 de mayo de 2008 (UTC) [ responder ]
Revertir sus ediciones no constructivas
Este es un aviso de que ahora tendré más libertad para revertir sus modificaciones a Drupal . Sus contribuciones son cada vez menos constructivas y sin sentido por las razones que he explicado en la página de discusión de Drupal.
Entonces no has estado leyendo la página de discusión con mucha atención. He pasado mucho más tiempo explicando mis modificaciones que realizándolas. -- Replysixty (discusión) 06:29, 9 de junio de 2008 (UTC) [ responder ]
Las secciones de crítica deberían incluir críticas, equilibradas con un razonamiento imparcial, no elogios entusiastas. Dejen de blanquear, por favor. Dejen de borrar. Sus comentarios afirmaban que estaban editando para tener en cuenta el punto de vista, ¡pero tienen ediciones extremas desde el punto de vista! Eliminaron una cita sin leerla realmente, asumieron con el título que el artículo (de Dries Buyart nada menos) no se aplicaba. Si no les gusta la redacción, reformúlenla de manera imparcial. Rogdor ( discusión ) 00:33 22 jun 2009 (UTC) [ responder ]
Uh, no. El artículo (que de hecho LEÍ, y sí, sé que es de Buyart) mostraba que cuando el almacenamiento en caché estaba activado, y cito del artículo, "el sistema de caché de Joomla mejora el rendimiento en un 12%, mientras que el sistema de caché de Drupal mejora el rendimiento en un 508%". Aunque Buyart admite que puede que no sea una mejora en el mundo real debido a que los usuarios no anónimos tienen contenido personalizado (y por lo tanto no usan el caché), el artículo citado es abrumadoramente una evaluación favorable del sistema de caché de Drupal. Entonces, ¿por qué está en una sección de críticas? ¿LO LEÍSTE?
A continuación, la primera oración de esta sección dice: "La optimización principal de Drupal se realiza a través del almacenamiento en caché orientado a visitantes anónimos que no están conectados al sistema. Las pruebas de rendimiento con optimizaciones pueden no reflejar el uso real en entornos dinámicos con usuarios conectados y tareas interactivas". Vale, genial. Pero, aparte de la confusa estructura de la oración, ¿tiene esto algún significado para un lector casual no técnico? ¿Cuántas palabras de moda puedes incluir en dos oraciones ("optimización principal", "entornos dinámicos", "tareas interactivas", etc., etc.)? ¿Y es de alguna manera una "crítica"? A mí no me parece así. Es solo un comentario vago sobre los mecanismos de aceleración.
No veo cómo algo de lo que agregué constituye un "elogio entusiasta". Reorganicé una sección sobre la "curva de aprendizaje" que no tenía nada que ver con la curva de aprendizaje (sino más bien con la facilidad de uso, que se trató en la sección anterior). Y me deshice de la sección Rendimiento/Escalabilidad que no brindaba una crítica clara desde el punto de vista de NPOV sobre el rendimiento o la escalabilidad de Drupal; se refería a un solo problema (almacenamiento en caché) sin mucha explicación de (1) qué es el almacenamiento en caché, (2) cómo se relaciona con el rendimiento/escalabilidad y (3) además de una comparación directa con otro CMS solo en términos de almacenamiento en caché, cualquier crítica sobre el rendimiento y la escalabilidad generales de Drupal. Era solo un montón de jerga técnica con una sola métrica y un solo competidor (contra el cual se desempeñó relativamente favorablemente: en su peor prueba, sirvió 13 páginas contra las 19 de Joomla, en todas las demás pruebas superó a Joomla). Fue NPOV porque estaba enmarcando un artículo (del desarrollador principal, nada menos) que presentaba un punto de referencia de caché positivo como una crítica negativa sin ninguna conexión lógica entre uno y otro. (Sin mencionar que ofrecía una descripción básica o una introducción sobre cómo se relaciona esta cuestión del "almacenamiento en caché" con el rendimiento y la escalabilidad) -- Replysixty (discusión) 18:49, 22 de junio de 2009 (UTC) [ responder ]
-- El artículo fue elegido y se refiere al almacenamiento en caché de Drupal que afecta al contenido estático y no refleja el rendimiento real de Drupal, algo que Dries Buyart sí menciona. Estás tratando de decir que no se aplica a toda la sección del rendimiento, pero era específico para ese aspecto. Vuelve a leerlo, no voy a copiar y pegar una sección como lo has hecho tú, puedes simplemente leerla. :P Rogdor ( discusión ) 22:31 23 jun 2009 (UTC) [ responder ]
He leído el artículo varias veces. No digo que el almacenamiento en caché no esté relacionado con el rendimiento. Lo que digo es que la sección no se lee bien y no establece una conexión clara entre "Rendimiento y escalabilidad" y un montón de cosas sobre el almacenamiento en caché y la comparación con Joomla. ¿Joomla es rápido? ¿Significa algo que Drupal sea más rápido que Joomla con el almacenamiento en caché activado? ¿Cuál es la relación con la escalabilidad? -- Replysixty (discusión) 01:52, 24 de junio de 2009 (UTC) [ responder ]
--Ah, y específicamente, "esforzarse" por hacer algo, o establecer una política sobre algo, en referencia al software, es absolutamente inútil desde el punto de vista informativo.
Estoy completamente en desacuerdo con que la política de Drupal sea información inútil. La sección se lee como si la política de Drupal/Dries fuera romper casualmente las rutas de actualización para el usuario final. Ese no es el caso, por lo que agregué una aclaración para que se entienda que esa no es la práctica de Drupal. -- Replysixty (discusión) 01:52, 24 de junio de 2009 (UTC) [ responder ]
Cualquiera que visite la página estará buscando cómo funciona el software, no cómo podría funcionar teóricamente en el futuro. No creo que nadie pueda decir honestamente que las rutas de actualización de Drupal son actualmente perfectas, la mayoría de los desarrolladores principales admitirían abiertamente que no lo son, por eso es algo por lo que se esfuerzan. Rogdor ( discusión ) 22:36 23 jun 2009 (UTC) [ responder ]
Si tienes evidencia de que la ruta de actualización de Drupal no es perfecta, publícala. Sería una crítica justa (por ejemplo, "algunos usuarios/revisores/etc. han informado de dificultades para actualizar sus sitios en versiones principales, como de la 5.13 a la 6.0"). Pero el artículo (tal como estaba cuando lo edité) se leía como si fuera la POLÍTICA de Drupal permitir tales fallas. Ese no es el caso. Es solo el caso desde el punto de vista de un desarrollador (aunque se podría argumentar que la compatibilidad con versiones anteriores es deseable, aunque a menudo no sea posible), así que eso es lo que aclaré.
El punto es que la página de Drupal debería ser informativa, no publicitaria. Rogdor ( discusión ) —Comentario anterior sin fecha agregado a las 03:21, 22 de junio de 2009 (UTC). [ responder ]
Estoy de acuerdo.
No creo que estés de acuerdo en absoluto, ahora estás hablando de retórica alternativa sobre algo que no debería decirse en el artículo. Si estás hablando de planes futuros para Drupal, al menos (observa que lo hice, pero lo borraste) incluye una referencia a las versiones en las que eso sucederá. Deja de desinformar y empieza a informar. Rogdor ( discusión ) 22:36 23 jun 2009 (UTC) [ responder ]
No sé de qué edición estás hablando aquí. Repito, no tengo ningún problema con un artículo que critique la escalabilidad o el rendimiento de Drupal (aunque tengo entendido que Drupal es notablemente escalable). Mi problema fue que la sección sobre escalabilidad estaba mal elaborada: era confusa, engañosa, incompleta y no estaba respaldada por el artículo citado. -- Replysixty (discusión) 01:52, 24 de junio de 2009 (UTC) [ responder ]
"Drupal se esfuerza por proporcionar una ruta de actualización sin fisuras" puede no haber sido la mejor expresión para utilizar. Aunque creo que son precisas... "La política de Drupal es proporcionar una ruta de actualización sin fisuras" puede haber sido mejor. Estoy de acuerdo con las críticas, pero tienen que ser críticas reales, tienen que ser comprensibles para el lector común y tienen que ser precisas. El artículo dejó la impresión de que cada vez que se actualiza Drupal se rompe el sistema para el usuario final; no aclaró que esto fuera una crítica (justa) para los desarrolladores . No quería decir que "Drupal proporciona una ruta de actualización sin fisuras para el usuario final" porque algunos usuarios pueden tener problemas para migrar sus sitios a nuevas versiones. Así que dije "se esfuerza por". Podría haber dicho "aspira a", "tiene una política para", "intenta", etc. Dije "se esfuerza"... No creo que eso sea muy publicitario, pero lo que sea. Cámbienlo. -- Replysixty (discusión) 18:49, 22 de junio 2009 (UTC) [ responder ]
Quieres que se te reconozca el mérito por no haber redactado el texto de la mejor manera y eso está bien, así es exactamente como crece Wikipedia, pero no has tenido esa cortesía conmigo ni con los demás. Sin embargo, la eliminación total de subsecciones enteras es algo que se suele discutir en las páginas de discusión, etc., antes de seguir adelante y eliminar una gran parte de algo en lo que otra persona estaba trabajando.
Mira lo que está arriba. Me atreví . Si quieres arreglar la sección, vuelve a colocarla. La miré y ni siquiera pude entender lo que intentaba decir. -- Replysixty (discusión) 01:52, 24 de junio de 2009 (UTC) [ responder ]
No tengo problemas con que hagas cambios, deshagas pequeños errores, etc., pero cuando eliminas por completo críticas honestas en una sección de críticas, debes entender que eso parece extremadamente parcial. Es como si estuvieras defendiendo a Drupal y me trataras como si lo estuviera atacando por hacer referencia a críticas bien conocidas incluso dentro de la comunidad principal de desarrolladores. Esto me hace suponer que tienes un interés personal y, si es así, ciertamente no deberías estar cerca del artículo en absoluto.
Soy un usuario (no profesional) de Drupal. (En el pasado he utilizado muchos otros CMS durante más de una década, por lo que estoy algo familiarizado con el tema), pero no diría que tengo un interés particular en el punto de vista. Mi problema con lo que añadiste es que, para mí, no estaba respaldado por el artículo citado, era muy técnico y no abordaba la crítica del rendimiento/escalabilidad generales. -- Replysixty (discusión) 01:52, 24 de junio de 2009 (UTC) [ responder ]
Si te interesa la información clara y equilibrada de Wikipedia, deberías ampliar lo que he escrito en lugar de criticarlo. No creo que tengas ningún problema con NPOV, creo que tienes un problema con cualquier crítica a Drupal, punto.
Como estaba tan mal escrito como se describe arriba, sentí que el artículo era más preciso sin esa sección. Hay otras críticas que creo que son válidas y están respaldadas y he contribuido a esas secciones. La crítica que agregaste fue lo suficientemente absurda y sin fundamento para mí como para que el punto de vista pareciera la motivación probable. ¿Estás seguro de que no te pagan por editar? Oh, es broma. -- Replysixty (discusión) 01:52 24 jun 2009 (UTC) [ responder ]
Ahora estoy mirando hacia atrás en la historia y viendo que otros también han tenido problemas similares con tus eliminaciones casi vandálicas.
Había otro editor que tenía una clara parcialidad. Si lees la historia completa, verás que un tercero neutral estuvo de acuerdo en que mis ediciones eran apropiadas. Así que te digo, si tuviste alguna dificultad personal con Drupal, Wikipedia no es un lugar para desahogar tu frustración, ni para universalizar tu experiencia como algo típico. En otras palabras, si la crítica no es notable y no está respaldada por algo más que una "investigación original", no debería estar en el artículo. -- Replysixty (discusión) 01:52, 24 de junio de 2009 (UTC) [ responder ]
Me interesaba aportar algo de equilibrio para que cualquiera que utilice la entrada de Wikipedia pueda tomar una decisión informada sobre el software. No creo que nunca lo veamos de esa manera, que es la esencia del sesgo.
¿Cuál es la esencia del sesgo? Déjenme en paz. Estoy a favor del equilibrio: estoy a favor de la crítica justa de Joomla, Drupal, lo que sea. Y estoy a favor de los artículos bien razonados, escritos y fundamentados. Si logras que tu sección sea coherente y esté bien citada, ¡estoy totalmente a favor! -- Replysixty (discusión) 01:52 24 jun 2009 (UTC) [ responder ]
La verdad es que yo mismo utilizo Drupal, pero no de manera profesional. No estoy defendiendo a Joomla (nunca lo he utilizado) ni a ningún otro CMS. Estas son críticas bien conocidas y habituales en la comunidad de Drupal y he notado una clara falta de abordaje neutral de las mismas en la entrada.
Si son bien conocidos y comunes, explícalos de forma clara para los que no son expertos en tecnología, incluye soporte y seré el primero en darte una palmadita en la espalda y decirte gracias. -- Replysixty (discusión) 01:52, 24 de junio de 2009 (UTC) [ responder ]
Si hubiera una crítica más que pudiera hacer a Drupal, sería que la comunidad tiene demasiados guardianes como usted que están tan interesados en proteger la imagen de Drupal como software respetado, que no crece ni mejora tanto como debería. Las fallas están muy bien defendidas y excusadas, una vez más, por personas como usted.
Estás haciendo muchas suposiciones descabelladas sobre mí y mis motivaciones. Mi motivación es sólo un artículo completo y bien escrito. Parece que tienes un gran resentimiento, lo que de nuevo sugiere una falta de NPOV. Y, por cierto, ¿dónde diablos "defendí" o "excusé" alguna falla en Drupal? ¡Simplemente escribe una buena sección y sustenta tu afirmación! -- Replysixty (discusión) 01:52, 24 de junio de 2009 (UTC) [ responder ]
Si tienes un interés personal, ten un poco de cordura y comprende la noción de recusarte. Me abstendré de editar porque no tengo ningún interés en una guerra de Wikipedia contigo. Deshice tu gigantesca eliminación del trabajo que agregué, espero que obtengas algo de claridad para dejar que alguien más lo limpie (si alguien siente que es necesario) o al menos dejar la crítica central intacta y editar sin el enfoque de un defensor para poner el software en la mejor luz posible.
Echaré un vistazo y haré las modificaciones que considere necesarias. Perdón por molestarte, pero estás completamente equivocado acerca de mi "interés personal". El hecho de que estés haciendo tales suposiciones debería hacerte cuestionar tu propio punto de vista. -- Replysixty (discusión) 01:52 24 jun 2009 (UTC) [ responder ]
En otras palabras, si realmente te gusta tanto el punto de vista no verbal, entonces haz lo que te propongas y demuéstralo. Edita con elegancia para variar. Personalmente, creo que probablemente seguirás usando excusas basadas en el punto de vista no verbal para promover tu propio sesgo obligatorio sobre el software del que probablemente dependas económicamente.
Si es así, no tenemos nada de qué hablar, no tiene sentido tratar de discutir algo racionalmente con alguien que intenta proteger su propio trasero. Rogdor ( discusión ) 22:40 23 jun 2009 (UTC) [ responder ]
Una explicación sobre las críticas a Drupal en cuanto a rendimiento y escalabilidad
Vale, respiremos hondo porque parece que nos hemos llevado mal y que ambos hemos hecho suposiciones. Por no hablar de que tenemos antecedentes similares en el tema en cuestión.
Me estoy enredando en expresar la crítica de forma clara y sin tecnicismos, intentando parecer lo más neutral posible. Lo explicaré con más detalle aquí para que al menos sepan lo que intento explicar:
La estructura modular de Drupal, incluso dentro del núcleo, da como resultado una gran cantidad de solicitudes SQL y de servidor interno que causan un uso moderado a alto en términos de rendimiento y serios problemas de escalabilidad. Cuantos más módulos se agregan, más se agrava el problema. La respuesta habitual es utilizar el almacenamiento en caché predeterminado de Drupal y reducir los módulos, pero toda la naturaleza modular está diseñada para módulos y sesiones interactivas que no se almacenan en caché (al menos no el sistema de almacenamiento en caché en general). Por lo tanto, para obtener el impresionante rendimiento en los puntos de referencia, el sitio debe ofrecer contenido muy diferente a los objetivos de la mayoría de los sitios de Drupal.
Se podría argumentar que cualquier sitio en cualquier software podría igualar ese rendimiento exacto con la adición de un caché para todo el sitio porque en ese punto solo está entregando páginas estáticas. Cualquiera que envíe páginas estáticas probablemente no debería usar Drupal, existen otros sistemas CMS más adecuados para ese entorno o simplemente usar HTML/XML simple.
El problema se agrava aún más con los módulos que entran en conflicto con el sistema de almacenamiento en caché.
La siguiente respuesta es almacenar en caché de forma selectiva en los niveles de SQL y servidor/código, pero eso queda fuera del escalamiento, o más bien es la respuesta habitual al escalamiento y no es realmente una solución de Drupal al problema: es parte del sistema de infraestructura. Esta solución sigue funcionando mejor en entornos menos interactivos. Cuanto más único sea, menos se puede almacenar en caché, ¿no es así? Los puntos de referencia están muy alejados del uso en el mundo real.
Dejando de lado el almacenamiento en caché, Drupal no escala bien de forma predeterminada, pero se pueden obtener grandes resultados con la infraestructura. Esa es una solución que lo cura todo: basta con escalar lo suficiente hasta que se solucione el problema. En términos más positivos, se podría suponer que la infraestructura de soporte suele ser lo suficientemente buena ahora que el rendimiento relativo de Drupal no es un problema. Pero, al final, lo que eso hace es limitar Drupal a aquellos que tienen la infraestructura para soportarlo, lo que reduce el mercado objetivo de Drupal.
El próximo Drupal 7 intenta solucionar el problema de las solicitudes SQL (eso es, en sí mismo, toda la referencia necesaria). No lo he analizado demasiado desde un punto de vista técnico, pero tengo entendido que están intentando fusionar las solicitudes SQL como una especie de solución irregular. Eso es una compensación en el rendimiento del código porque no se fusionan al principio, sino que salen en ramas y se vuelven a combinar, por lo que reducir la velocidad en PHP tiene sentido.
Lo expreso de esta manera para que tengas una mejor idea de cuál es la crítica real que intento transmitir. No estoy sugiriendo que se escriba en el artículo textualmente, es demasiado largo para el tema en cuestión y no tiene fuentes de referencia (aunque podría ser solo de una o dos referencias, la mayoría son conclusiones lógicas basadas en el problema inicial). Se basa en lo que yo diría que es un conocimiento relativamente común (excepto por la última parte sobre Drupal 7).
Un problema con las fuentes es que las personas que se han encontrado con estos problemas recurren a otro software en lugar de intentar solucionarlo nadando contra corriente, pero por eso me gustaría verlo en el artículo, porque no está bien abordado. Tal vez esto haga que Wikipedia sea el lugar equivocado, pero honestamente no estoy tratando de hacer algo malo con esto, simplemente tenía sentido para mí como el primer lugar donde la gente buscaría la información.
No tengo muchas ganas de hacerlo si también estoy luchando contra corriente. Me gustaría verlo ahí, pero si después de leer lo que he dicho aquí no estás convencido de que sea válido para el artículo, entonces no voy a darle vueltas al asunto. Rogdor ( discusión ) 04:27 24 jun 2009 (UTC) [ responder ]
¿Es algo así como esto lo que estás tratando de decir?
Debido a su entrega de contenido dinámico y su diseño modular "enchufable", el funcionamiento de Drupal tiende a requerir más sobrecarga computacional que otros CMS que ofrecen características similares. Como Drupal crea páginas web dinámicas personalizadas sobre la marcha , cada módulo y tema único puede requerir sus propias consultas de base de datos. Por lo tanto, Drupal debe consumir más ciclos de CPU para crear cada página. Esto crea un problema tanto para el rendimiento como para la escalabilidad de Drupal, ya que los CMS que no admiten módulos de complemento pueden optimizar mejor internamente el acceso a la base de datos para una representación de páginas más eficiente y escalable. Una solución propuesta para este problema es el sistema de almacenamiento en caché central de Drupal, que almacena páginas estáticas, lo que reduce la necesidad de volver a generarlas. Desafortunadamente, las páginas estáticas son utilizadas principalmente por visitantes anónimos, por lo que los usuarios registrados no recibirán muchos de los beneficios del almacenamiento en caché. Otras soluciones, incluido el almacenamiento en caché solo de bloques, formularios y temas, el almacenamiento en caché de SQL por parte del propio servidor de base de datos y las mejoras propuestas para Drupal 7, pueden ayudar a mitigar estos problemas de rendimiento y escalabilidad.
No sé si esto comienza a capturar de qué estás hablando, pero si es así, espero que cada afirmación anterior esté respaldada por fuentes citadas, y que se demuestre que el problema en sí es notable, es decir, "Este problema ha sido citado como una razón para no adoptar Drupal por la corporación XYZ" o "Una conferencia de administradores de CMS votó que esto es un obstáculo importante que Drupal necesita superar" o algo como "este problema es exclusivo de Drupal" o "este es un problema común con todos los CMS, pero los avances en tecnologías de acceso a bases de datos, incluyendo xy y z, hacen que sea probable que no sea un problema en el futuro" o ALGO que indique que esto SÍ pertenece a una sección de críticas. Idealmente, los términos técnicos como "diseño modular" o "sobrecarga computacional" o "representación de páginas" o "almacenamiento en caché" deberían estar vinculados al artículo de Wikipedia correspondiente. Sin embargo, mi gran pregunta es: ¿es esta una crítica notable a Drupal? ¿Dónde están las grandes corporaciones que han tenido problemas de escalabilidad y rendimiento? Si alguien en una conferencia diera un discurso diciendo "por eso Drupal apesta..." sería de gran ayuda decir que sí, que esto es algo real, en lugar de decir "oh, esto podría ser un problema, pero en realidad no lo es..." en cuyo caso ciertamente no corresponde. De todos modos, eso es lo que pienso. Necesito ir a comer ahora. -- Replysixty (discusión) 05:05, 24 de junio de 2009 (UTC) [ responder ]
Eso es mucho más coherente y está más cerca de la realidad. No es que otros CMS no utilicen módulos, sino que Drupal depende totalmente de ellos, hasta el punto de que su núcleo está formado por numerosos módulos. Por lo tanto, los valores predeterminados son más exigentes que otros CMS porque ya están modularizados.
¿Estás seguro de esto? ¿Otros CMS no modularizan sus funciones básicas? Además, ¿no podría el diseño modular ser una VENTAJA de rendimiento, porque permite fácilmente a los administradores restringir Drupal a solo aquellos módulos que desean? Por ejemplo, un sistema con 15 funciones codificadas sería mucho más grande y más lento que un sistema Drupal donde solo 1 de 15 módulos está activado, ¿verdad? Hablando por mí mismo, no uso muchos de los módulos básicos; ni siquiera se verifican en la sección Módulos. Esto significa que las tablas nunca se crean, el código nunca se carga en la memoria ni se ejecuta. Entonces, ¿quizás haya una ventaja de rendimiento, así como una penalización para los módulos, dependiendo de cuáles se usen...? -- Replysixty (discusión) 01:41, 25 de junio de 2009 (UTC) [ responder ]
¿Estás comparando con otros CMS o frameworks? Probablemente con frameworks sí, pero los CMS normalmente no. Hay modularidad y hay modularidad. Modularizar el código (es decir, bibliotecas de código) no es lo mismo que cargar o descargar paquetes específicos como lo hace Drupal. Por ejemplo, el enfoque en la modularidad del código puede encapsular funciones SQL, mientras que la modularidad de Drupal implica separar en bloques de construcción las características. El sistema comparativo más cercano es Joomla!/Mambo (Joomla! es una bifurcación de Mambo), por lo que, considerando su comparación, la modularidad de Drupal está muy por encima del resto.
Así que sí, estoy seguro.
En teoría, se obtiene flexibilidad, que es precisamente el objetivo de Drupal, mientras que la mayoría de los CMS se centran en una sola cosa (foros, blogs, documentación de oficina o incluso wikis), Drupal intenta ser capaz de abarcar todo eso y lo que sea más. El rendimiento y la facilidad de uso son los puntos débiles, tanto desde el punto de vista lógico como en la realidad. No es muy distinto del viejo dicho del "todoterreno": si te centras en una sola cosa, la reutilización de las piezas no es necesaria.
Pero ¿qué pasa con el hecho de que la modularidad de Drupal permite a los administradores NO incluir/cargar ciertos módulos que de otra manera serían cargados por un CMS rival? ¿Acaso esto no promueve un uso MÁS eficiente de los recursos en comparación con un CMS que incluye todo (incluso el fregadero de la cocina)? Un CMS con la misma funcionalidad que Drupal con todos los módulos implementados puede ser más rápido, ya que podría optimizar las llamadas a la base de datos, etc. Pero una vez que comienzas a desactivar los módulos de Drupal que no usas, en algún momento Drupal debe obtener la ventaja. -- Replysixty (discusión) 18:31, 25 de junio de 2009 (UTC) [ responder ]
Esto se ve agravado por los populares módulos Views, CCK y otros relacionados. Es muy diferente, por ejemplo, de un módulo de cualquier otro CMS que inserta un feed de Flickr o de un software de foros instalado con todas las funciones. La mayoría de los demás CMS suelen ejecutarse en instalaciones predeterminadas, tal vez con uno o dos módulos. Esa es una diferencia notable con respecto a Drupal, incluso solo en la instalación predeterminada (y mi experiencia con Drupal es que las instalaciones predeterminadas son poco frecuentes).
Aparte de mi pregunta sobre los posibles aumentos de rendimiento a partir de un diseño modular, ¿estamos simplemente especulando en cuanto a Drupal en comparación con otros módulos? ¿O es un hecho establecido que la mayoría de los otros CMS pueden tener uno o dos módulos activados? Si es así, ¿qué módulos y cuál es la fuente citada? Las comparaciones comparativas serían muy útiles. Luego, suponiendo que la crítica se basa en hechos y está bien explicada, debemos preguntarnos si es notable... -- Replysixty (discusión) 01:41, 25 de junio de 2009 (UTC) [ responder ]
Drupal está diseñado de forma modular para lograr flexibilidad. Es fácil hacer referencia a él, pero no es necesario. Cada módulo realiza sus propias llamadas SQL, por lo que si el núcleo realiza muchas llamadas SQL en comparación con otros CMS, es lógico y obvio concluir que cuantos más módulos realicen más solicitudes SQL, mayor será el total. 1 + 1 = 2. No se necesitan referencias, es simplemente matemática aditiva simple, no se puede obtener una lógica más simple que esa.
Excepto que esto puede ser un impacto en el rendimiento totalmente insignificante en términos del mundo real. O puede ser que Drupal haya optimizado la forma en que maneja las llamadas a la base de datos de módulos de alguna manera interesante: tal vez todas las llamadas a módulos se almacenan en caché, se optimizan y luego se ejecutan en un único acceso a la base de datos por la API... No tengo idea. El punto es que, si bien la discusión es interesante, todavía me parece especulación... Si comenzara con una conclusión: "Los usuarios están de acuerdo: Drupal es lento y estos puntos de referencia muestran que es lento en relación con otros 5 CMS" y luego explorara las razones de la desaceleración, incluidas más solicitudes SQL, eso tendría sentido y probablemente debería ir en el artículo. Pero para comenzar con "Drupal es modular, modular significa más solicitudes SQL, más solicitudes SQL deben significar que Drupal es lento..." No lo sé... -- Replysixty (discusión) 18:31, 25 de junio de 2009 (UTC) [ responder ]
El artículo de Dries ya hace referencia a un punto de referencia comparativo, solo argumenta que el almacenamiento en caché compensa la diferencia, pero documenta que hay una diferencia en primer lugar.
Pero (1) el artículo de Dries tiene tres años, (2) dice que Drupal es más lento que Joomla sin almacenamiento en caché al manejar 14 solicitudes en lugar de 19 (algo así que no lo tengo frente a mí), y (3) nuevamente, no sé si constituye una crítica notable... si Joomla es el CMS más rápido que existe y Drupal está en segundo lugar (esto es inventado, pero lo digo...) ¿significa esto que Drupal es lento? ¿Cuál es el contexto en comparación con otros CMS o con el uso real de los administradores? Puedo decir que un Honda Civic tiene una velocidad máxima más lenta que un Corolla, pero ¿significa eso que una crítica común al Civic es que tiene un rendimiento pobre? -- Replysixty (discusión) 18:31, 25 de junio de 2009 (UTC) [ responder ]
Las notas de Drupal 7 también documentan que están reduciendo las consultas SQL, lo que indica que sigue siendo un problema. ¿Por qué hay una exención de responsabilidad de 2006 que se aleja de la conclusión inherente y se lee como si fuera un problema del pasado? No lo es, es exactamente como era hasta que sale Drupal 7 (y luego quedará obsoleto).
Nuevamente, es probable que haya muchos cambios en Drupal 7. Pero una mejora en 7 no necesariamente corresponde a un problema notable en 6. Volviendo a la analogía del auto , el nuevo Civic puede obtener algunos MPG más del motor, pero eso no significa necesariamente que sea apropiado poner una sección de "crítica: kilometraje" en el artículo de Wikipedia del Civic anterior. ¿Ves lo que digo? -- Replysixty (discusión) 18:31, 25 de junio de 2009 (UTC) [ responder ]
Podría encontrar más artículos que señalen muchas consultas SQL y los pros y contras del diseño modular, pero además de salirse del alcance, se está volviendo una tontería, ¿cuántas referencias necesita?
Es necesario hacer referencia a que, en general, el rendimiento y la escalabilidad de Drupal son un problema para la gente. -- Replysixty (discusión) 18:31, 25 de junio de 2009 (UTC) [ responder ]
Estamos saturando las referencias. Las citas se están volviendo excesivas en cosas que son claramente ciertas. Esto me lleva de nuevo a mi queja original, porque, según tengo entendido, la política de Wikipedia para artículos bien referenciados no equivale a exigir una referencia en cada afirmación o, de lo contrario, a la eliminación inmediata. Eso es una vigilancia excesiva y dificulta la contribución. Esto es lo que me molestó inicialmente.
Estoy buscando alguna cita que indique que el rendimiento y la escalabilidad son un problema importante en Drupal. Una revisión crítica, una encuesta en línea, una preponderancia de mensajes del tipo "¿POR QUÉ DRUPAL ES TAN LENTO?" de una amplia cantidad de usuarios... ¡algo! Ahora mismo tienes una teoría sobre que más módulos llevan a más consultas que conducen a un rendimiento reducido en el mundo real cuando el almacenamiento en caché no está activado, o para aquellos usuarios que no cargan contenido almacenado en caché. No creo que esto sea suficiente. -- Replysixty (discusión) 18:31, 25 de junio de 2009 (UTC) [ responder ]
He aquí una idea: tal vez lo que tienes no sea en realidad una crítica al rendimiento y la escalabilidad sino una crítica al diseño modular de Drupal. En ese caso, la sección debería llamarse "Diseño modular" y podría leerse algo como que la modularidad de los complementos de Drupal tiene como objetivo ofrecer al sistema flexibilidad en características y funcionalidad. Sin embargo, este diseño puede tener un costo de rendimiento en comparación con los CMS no modulares. [ cita requerida ] Por ejemplo, un CMS no modular puede optimizar sus llamadas a la base de datos, mientras que los componentes modulares de Drupal hacen cada uno sus propias solicitudes de base de datos independientes entre sí. [ cita requerida ] Estas consultas de base de datos independientes toman más tiempo y podrían dar como resultado una generación de páginas más lenta. Por otro lado, un diseño modular permite a los administradores desactivar funciones que no usan, lo que puede terminar ahorrando consultas de base de datos en comparación con un CMS no modular similar. Además, el almacenamiento en caché , tanto a nivel de aplicación como de base de datos, puede ayudar a mitigar esto. [ cita requerida ] Los desarrolladores de Drupal están trabajando para abordar estos problemas y mejorar el rendimiento mediante optimizaciones en Drupal 7. [ cita requerida ] -- Replysixty (discusión) 18:31, 25 de junio de 2009 (UTC) [ responder ]
Por ejemplo: si dices que la mayoría de los CMS tienen una forma de insertar y mostrar imágenes de forma predeterminada, pero que para Drupal necesitas un módulo de terceros, eso es verdad y es poco probable que haya algún argumento en contra, así que ¿por qué es necesario citarlo? Si hubiera una disputa o confusión, seguro, pero nunca he oído una disputa sobre si Drupal está enfocado como la mayoría de los otros CMS, lo que se discute es si Drupal es mejor en su diseño modular.
Vea lo anterior. Sin embargo, en su ejemplo, necesitaría una cita más para indicar que existe la falta de compatibilidad con imágenes, pero que es un problema. Es decir, un artículo en CMS Weekly titulado "¡El manejo de imágenes de Drupal es una porquería!" sería una mejor cita que simplemente un enlace al módulo ImageCache o lo que sea si el artículo de WP hace una crítica al diseño modular de Drupal. -- Replysixty (discusión) 18:31, 25 de junio de 2009 (UTC) [ responder ]
Es de destacar que Drupal utiliza módulos para lograr los mismos resultados que los CMS, que están diseñados más como soluciones completas. Es un enfoque diferente y, en muchos sentidos, define a Drupal. En mi humilde opinión, así es como debería orientarse todo el artículo sobre este tipo de diferencias, porque, tal como está, resulta bastante confuso qué hace exactamente Drupal si nos basamos en la entrada de Wikipedia. Rogdor ( discusión ) 11:35 25 jun 2009 (UTC) [ responder ]
No sé si estoy de acuerdo en que las referencias deben indicar las repercusiones, solo indicar que los problemas existen y que afectan tanto a los usuarios como a los usuarios potenciales. No es que no sea un problema, es que como problema actúa como un filtro y una barrera para quienes probablemente implementen el software en soluciones que funcionen. Encontrar ejemplos de intentos que no funcionan o personas que se han topado con los problemas es fácil, pero encontrar escritos o análisis de errores confiables no lo es.
Exactamente lo que pienso. Uno podría ir al foro y encontrar ejemplos de todo tipo de problemas que la gente está teniendo al configurar Drupal. El otro tipo que publicó su problema particular, algo que odiaba sobre el comportamiento de filtrado predeterminado de Drupal, simplemente no estaba de acuerdo con el diseño de Drupal y lo publicó como una crítica. Pero si bien hay millones de personas que pueden tener este o aquel problema, creo que la sección "Crítica" debería ser para problemas ampliamente reconocidos y notables con el comportamiento/licencia/costo/utilidad/etc. de Drupal, no simplemente un lugar para discutir un problema que una sola persona puede tener. También debería ser fácil de entender para un profano. -- Replysixty (discusión) 01:41, 25 de junio de 2009 (UTC) [ responder ]
¿No es el rendimiento, aunque discutido (el factor caché), suficientemente conocido y relacionado con el impacto como para ser notable? Las disputas en sí mismas son un reconocimiento de que es un problema importante. La crítica no debería tener que demostrar una cosa o la otra, simplemente decirlo. Rogdor ( discusión ) 11:35 25 jun 2009 (UTC) [ responder ]
¿El factor caché es un tema de discusión bien conocido? Nunca había oído hablar de él antes de que lo mencionaras, así que me inclino a decir que no. ¿Dónde has visto que este tema es un tema de discusión candente? Por favor, cita esas fuentes, porque puede que yo esté fuera de esto, pero no he visto ninguna discusión al respecto... -- Replysixty (discusión) 18:31, 25 de junio de 2009 (UTC) [ responder ]
En cuanto al tema de las grandes corporaciones que tienen problemas de escalabilidad y rendimiento, creo que esa es la parte que se destaca, que Drupal está más diseñado para ellos y (al menos en este número) no es tan apropiado para usuarios sin opciones de escalabilidad (alojamiento compartido, por ejemplo, o presupuesto limitado). La falta de una declaración de enfoque para el software es notable, incluso el párrafo superior no puede decidir si Drupal es un CMS o un Framework o algo más. Sé que no han aclarado estos enfoques dentro de la comunidad Drupal, pero la entrada de Wikipedia podría al menos indicar audiencias objetivo y limitaciones de usar Drupal fuera de ese ámbito. Ahí es donde entran en juego las críticas, porque en este caso están definiendo Drupal tanto como el resto del artículo.
Bueno, creo que Drupal puede ser tanto un CMS como un framework CMS. Es un conjunto de partes que se pueden usar para construir un sitio web sofisticado, pero que se empaquetan por defecto en un sitio "básico" de muestra. Una analogía (pobre) podría ser una caja de legos: puedes comprar una caja de legos que se usan para construir un cohete; los mismos legos se pueden usar para construir un tren o un barco. Hay un cohete en la caja, así que podrías decir "Esta caja contiene un cohete, pero también se puede usar para construir otras cosas..." -- Replysixty (discusión) 01:41, 25 de junio de 2009 (UTC) [ responder ]
También he utilizado la analogía de Lego. Personalmente, diría que es un marco para crear un CMS (y entregar contenido, pero eso está incluido en la mayoría de los CMS). Esto es inherente a la mayoría de los usos prácticos: las empresas de diseño web instalan, configuran y personalizan/codifican sitios Drupal para los clientes y luego el cliente utiliza el producto final como un CMS. Calculo que ese es el uso típico de Drupal, que es muy diferente a, por ejemplo, Wordpress, que normalmente lo utiliza el usuario final directamente como un CMS para blogs. ¡Esa es una diferencia muy notable!
Por cierto, conozco al menos a una persona que usa Drupal como blog personal. No tengo ni idea de cuál es el "uso típico": si es corporativo, personal, para aficionados, para blogueros... no lo sé. Podría ser cualquiera de esas cosas... pero si tienes los datos, te diría que los publiques, porque tienes razón: son importantes... por ejemplo, si tuvieras algo que dijera que la encuesta XYZ mostró que el 56% de los sitios de Drupal se usan para fines corporativos, el 14% para fines políticos, el 20% para fines personales y el 10% para "otros" fines , sería muy esclarecedor. -- Replysixty (discusión) 18:31, 25 de junio de 2009 (UTC) [ responder ]
Personalmente, no puedo hablar de la capacidad de Drupal para escalar. Recibo muy pocos visitantes en mi sitio y nunca he tenido que abordar este tema. Sin embargo, incluso si me hubiera ido fatal escalando Drupal, sería totalmente irrelevante para el artículo en sí, ya que mis experiencias no son suficientes para citarlas. Si, por otro lado, Drupal hubiera ganado el premio al "Sistema web menos escalable" de CMS Magazine en 2009, esa podría ser una crítica notable.
Me estoy desviando hacia mi opinión personal: esto se debe, en parte, a una frustración con Wikipedia como una especie de enciclopedia de cultura pop. Una revista y un premio como ejemplos de referencias autorizadas, eso parece típico de las solicitudes de referencias. Usando otro ejemplo: sucede un evento mundial y se hacen referencias a experiencias de primera mano en Wikipedia en un artículo: se eliminan rápidamente y se reemplazan por enlaces a CNN y AP, porque son más "autorizadas", pero lo que ha sucedido es que ahora los relatos son menos verdaderos, menos directos. Estamos aceptando referencias más vagas de terceros porque se supone que debemos confiar más en la fuente. Ahora bien, como dije, es una opinión personal, pero yo calificaría tus experiencias reales más alto que una revista que está más interesada en la imagen pública como apostar en un caballo. Wikipedia ha migrado de esta manera porque ha atraído mucho abuso en los artículos, pero es una pena que, por lo general, las referencias respetadas sean, en mi humilde opinión, las incorrectas. No puedo cambiar eso y no estoy tratando de hacerlo aquí, solo estoy siendo brutalmente honesto al respecto.
No puedo explicar el razonamiento de Wikipedia sobre citar fuentes; supongo que simplemente es preferible que haya al menos una distancia de una persona entre el tema del artículo y el artículo en sí. Hay fallas inherentes en esto (aún puedes escribir un artículo en algún lugar y luego publicarlo como fuente), pero entiendo el argumento. Esta puede ser una situación en la que no hay una solución perfecta. Sería bastante loco tener una política que alentara a todos a publicar sus experiencias subjetivas sobre cada tema. En otras palabras, puede que en algunos sentidos seas la mejor persona para escribir una entrada sobre ti mismo. Pero en muchos sentidos eres la peor persona para hacerlo. Entiendo por qué, para una enciclopedia, WP te pide que no hagas esto, y creo que el mismo tipo de lógica se extiende a los informes originales y en primera persona. Wikipedia no es un periódico ni un blog; su objetivo es ser una referencia enciclopédica e incluir información consensuada... pero tu punto es muy acertado, y yo estoy en una posición intermedia en el tema... -- Replysixty (discusión) 18:31 25 jun 2009 (UTC) [ responder ]
Volviendo al tema del escalado, me gustaría tener todavía el enlace y tal vez lo busque, pero un ejemplo perfecto fue el sitio web de un dibujante de historietas que mostraba dinámicamente sus tiras y, como tal, el almacenamiento en caché era inútil y muy rápidamente su servidor alcanzó sus límites. Tuvo que decidir si escalar más, cambiar de software o de diseño. Estaba preguntando cuánto escalado pensaba alguien que podría necesitar para poder ponerle precio y, al igual que en esta situación, nadie lo sabía porque los puntos de referencia en situaciones de escalado simplemente no existen. Ahora bien, la razón por la que cuento esto es que no necesitamos la misma información que él necesitaba, no necesitamos puntos de referencia detallados, sino simplemente que el problema existe, que limita el uso/las opciones del software. Rogdor ( discusión ) 11:35, 25 de junio de 2009 (UTC) [ responder ]
Si tienes ese artículo sobre el caricaturista, sería genial mostrar que se trata de un problema del mundo real (y no simplemente teórico). --- Replysixty (discusión) 18:31, 25 de junio de 2009 (UTC) [ responder ]
Todo esto podría resumirse en la naturaleza/diseño de Drupal con pros y contras sin siquiera una sección de críticas, pero no creo que esté preparado para abordar todo el alcance del artículo. Supongo que estoy llegando a la conclusión de que sin un artículo general que defina exactamente qué es Drupal, cualquier crítica va a sonar demasiado negativa/rencorosa. Rogdor ( discusión ) 06:34 24 jun 2009 (UTC) [ responder ]
No me preocupa la negatividad: una sección de críticas, por su naturaleza, tratará aspectos "negativos" de Drupal. Sólo quiero que todo lo que esté allí pase las pruebas de ser notable, fácil de entender, preciso y bien respaldado por citas objetivas. Tiene que ser más que simplemente una discusión interesante. En mi humilde opinión, para ser notable, la crítica debe representar una opinión de consenso o una crítica de una autoridad. Por lo tanto, si estamos hablando de problemas de rendimiento, necesito evidencia de que esto es real y justamente un problema para Drupal, y me gustaría contexto: comparación con otros CMS, una discusión de algún defecto estructural o de diseño, el impacto que tiene el problema e incluso cualquier solución propuesta... -- Replysixty (discusión) 01:41, 25 de junio de 2009 (UTC) [ responder ]
Consulte los comentarios de notoriedad anteriores. Y a riesgo de repetirme, las diferencias de estructura y diseño de Drupal deberían ser parte del artículo en sí y, hasta cierto punto, ya lo son; si son un defecto o no es el objetivo de formular la crítica en primer lugar. El lector puede decidir, nosotros solo proporcionamos la información. Podría ser mucho más claro si se hiciera menos hincapié en intentar probarlo o refutarlo de una manera enrevesada en lugar de simplemente usar el sentido común.
Me estoy cansando de esto, es realmente bastante simple y se está volviendo demasiado complicado.
Propuesta de eliminación de Max Machine Night Hawk
Se ha añadido una plantilla de eliminación propuesta al artículo Max Machine Night Hawk, sugiriendo que se elimine de acuerdo con el proceso de eliminación propuesto debido a la siguiente preocupación:
Por favor, considere mejorar el artículo para abordar las cuestiones planteadas porque, aunque eliminar el aviso de eliminación evitará la eliminación a través del proceso de eliminación propuesto , el artículo aún puede eliminarse si cumple con alguno de los criterios de eliminación rápida o puede enviarse a Artículos para eliminación , donde puede eliminarse si se llega a un consenso para eliminarlo. RadioFan (discusión) 02:09 4 jul 2009 (UTC) [ responder ]
Agosto de 2009
Actualmente pareces estar involucrado en una guerra de ediciones según las reversiones que has hecho en Come as You Are (canción de Nirvana) . Ten en cuenta que la regla de las tres reversiones prohíbe hacer más de tres reversiones en una sola página en un período de 24 horas. Además, los usuarios que realicen una gran cantidad de reversiones en disputas de contenido pueden ser bloqueados por guerra de ediciones, incluso si técnicamente no violan la regla de las tres reversiones . Si continúas, es posible que se te bloquee la edición . No reviertas ediciones repetidamente, sino que usa la página de discusión para trabajar en la redacción y el contenido que obtengan un consenso entre los editores. Si es necesario, busca la resolución de la disputa . JD554 ( discusión ) 10:03, 6 de agosto de 2009 (UTC) [ responder ]
BFS
Gracias por revitalizar la página de BFS , esa eliminación rápida me irritó, aunque el debate que esto generó (http://lwn.net/Articles/351058/) es útil y probablemente justifique su notoriedad con el tiempo. EasyTarget ( discusión ) 11:45 9 sep 2009 (UTC) [ responder ]
Modificación cianógena
Hola, gracias por trabajar en la página de CyanogenMod , definitivamente necesita ayuda (otro superviviente de la eliminación rápida también, aparentemente). Tenía principalmente dos propósitos al comenzar la sección "Beneficios para el usuario"/"Filosofía": - escribir en un lenguaje sencillo el beneficio principal de ese firmware (aunque no es mi lengua materna, y se nota) - incluir un montón de enlaces de referencia que mencionen a CyanogenMod (todos lo hacen, incluso cuando un título no lo menciona) para ayudar a establecer la notoriedad, ya que el AfD simplemente se ha retrasado. Dicho esto, estoy totalmente de acuerdo con alterar/fusionar/destruir drásticamente esa sección (como uno de tus mensajes de confirmación insinuó (creo)), solo espero que podamos mantener suficientes enlaces de referencia para que la notoriedad se pueda establecer rápidamente cuando el AfD se despierte nuevamente. 66.68.113.5 ( discusión ) 09:57, 11 de septiembre de 2009 (UTC) [ responder ]
Invitación a editar usuario: Virdi/CyanogenMod
El artículo de CyanogenMod fue modificado y movido a User:Virdi/CyanogenMod hasta que cumpla con los requisitos de Wikipedia. Por favor, ayude a mejorarlo y a obtener las fuentes necesarias. Podemos mover el artículo nuevamente una vez que esté listo.
Un editor ha propuesto que se eliminen uno o más artículos que usted ha creado o en los que ha trabajado . El artículo propuesto es CyanogenMod . Agradecemos sus contribuciones, pero el autor de la propuesta no cree que el artículo cumpla con los criterios de Wikipedia para su inclusión y ha explicado por qué en su propuesta (consulte también Wikipedia:Notabilidad y " Lo que Wikipedia no es ").
También puede editar el artículo durante la discusión para mejorarlo, pero no debe eliminar la plantilla de artículos para eliminación de la parte superior del artículo; dicha eliminación no finalizará el debate sobre la eliminación.
Nota: esta es una notificación automática de un robot . No tengo nada que ver con este artículo ni con la propuesta de eliminación y no puedo hacer nada al respecto. -- Erwin85Bot ( discusión ) 01:15, 6 de diciembre de 2009 (UTC) [ responder ]
Archivo:Seth McFarlane habla en el mitin de la WGA.jpg
Gracias por esta foto (y otras también :). La uso aquí. Saludos cordiales Przykuta ( discusión ) 10:14 25 abr 2010 (UTC) [ responder ]
Notificación de enlace de desambiguación
Hola. Cuando editaste recientemente Rooting (Android OS) , agregaste enlaces que apuntaban a las páginas de desambiguación de la aplicación y la tableta PC (verifica para confirmar | soluciona con el solucionador Dab). Estos enlaces casi siempre son involuntarios, ya que una página de desambiguación es simplemente una lista de títulos de artículos del tipo "¿Quisiste decir…?". Lee las preguntas frecuentes • Únete a nosotros en el WikiProject de DPL .
Las guerras de ediciones son disruptivas independientemente de cuántas reversiones hayas realizado ; es decir, los editores no tienen automáticamente "derecho" a tres reversiones.
No edites la guerra incluso si crees que tienes razón.
Si te encuentras en medio de una disputa de edición, utiliza la página de discusión del artículo para discutir los cambios controvertidos; trabaja para lograr una versión que represente el consenso entre los editores. Puedes publicar una solicitud de ayuda en un tablón de anuncios adecuado o buscar una resolución de disputas . En algunos casos puede ser apropiado solicitar protección temporal de la página . Si te involucras en una guerra de ediciones, es posible que se te bloquee la edición. Sudo Ghost 00:19, 9 de marzo de 2012 (UTC) [ responder ]
Modificación cianógena
Hola. Me doy cuenta de que me concentré casi por completo en la tabla del historial de versiones en noviembre, pero quería que mis comentarios se aplicaran también a la tabla de dispositivos compatibles. (Pensé que lo había mencionado en alguna parte. Lo siento si no quedó claro). El historial de versiones era muy, muy malo en ese momento [2], así que ese era el problema más grande. Aunque estoy de acuerdo con Sudoghost sobre los dispositivos compatibles, ahora me preocupa menos porque el historial de versiones es mejor y, para ser honesto, no voy a pelearme por eso. Espero que esto aclare las cosas. – Steel 00:45, 18 de marzo de 2012 (UTC) [ responder ]
Notificación de enlace de desambiguación para el 10 de diciembre
Hola. Gracias por tus recientes modificaciones. Wikipedia agradece tu ayuda. Sin embargo, hemos notado que cuando editaste Randy Quaid , agregaste un enlace que apunta a la página de desambiguación The Outer Limits . Estos enlaces casi siempre son involuntarios, ya que una página de desambiguación es simplemente una lista de títulos de artículos del tipo "¿Quisiste decir…?". Lee las preguntas frecuentes • Únete a nosotros en el WikiProject de DPL .
Hola, soy ReferenceBot . He detectado automáticamente que una edición realizada por ti puede haber introducido errores en la referenciación. Es lo siguiente:
Por favor, revisa esta página y corrige los errores resaltados. Si crees que se trata de un falso positivo , puedes informarlo a mi operador. Gracias, ReferenceBot ( discusión ) 00:36 10 may 2015 (UTC) [ responder ]
florina
Gracias por prestarle atención especializada al artículo de Carly Fiorina . Esto es solo un recordatorio amistoso sobre la política de WP:3RR . No he examinado tus ediciones con suficiente atención para ver si has superado el umbral de 3RR, pero pensé que no estaría de más recordártelo, dada la cantidad de ediciones de hoy. Saludos. Anythingyouwant ( discusión ) 02:20, 11 de mayo de 2015 (UTC) [ responder ]
He aquí un pequeño pero sencillo ejemplo de una de tus reversiones. Anythingyouwant ( discusión ) 15:13 11 may 2015 (UTC) [ responder ]
Ninguno de nosotros sabe lo que es una reversión . Quitar una palabra innecesaria al final de una oración no es una reversión de nada. Es una edición sencilla. No deshace ninguna edición anterior específica y no devuelve el documento a un estado anterior... ¿Ese es tu ejemplo de una reversión? ¿Eh? -- Replysixty (discusión) 05:34, 12 de mayo de 2015 (UTC) [ responder ]
Esa es una respuesta interesante, gracias. También puede ser que ninguno de nosotros sepa qué es una reversión. :-) Según WP:3RR , "Una edición o una serie de ediciones consecutivas que deshacen las acciones de otros editores, ya sea en su totalidad o en parte, cuentan como una reversión". En el ejemplo que señalé, deshizo la acción que insertó la palabra "ampliamente". Pero tiene razón en que la definición de "reversión" en Help:Reverting es diferente. Así que investigaré un poco más y me pondré en contacto con usted. Una cosa que espero que vea es que no estaba (y no estoy) tratando de acusarlo de nada. Simplemente estaba ofreciendo un recordatorio, pero usted ha señalado un posible error de mi parte. Saludos. Anythingyouwant ( discusión ) 05:57, 12 de mayo de 2015 (UTC) [ responder ]
Vaya. Vale, mmm. Voy a seguir con mi trabajo de edición y, si detectas algún problema, házmelo saber. Es gracioso porque no me sentí en una situación de guerra de ediciones ni en disputa con nada de lo que se había editado entre mis ediciones; simplemente me tomé un descanso y volví unas horas más tarde y lo retomé donde lo había dejado... Por cierto, creo que la intención de las tres reversiones es claramente evitar una situación en la que la gente vaya y venga revirtiendo sin fin (a través del botón de reversión o mediante una edición manual prácticamente idéntica), pero bueno... Dejaré el estudio talmúdico a otros... -- Replysixty (discusión) 08:18, 13 de mayo de 2015 (UTC) [ responder ]
Las reglas podrían ser mucho más claras y los resultados dependen mucho de qué administrador se involucre. De todos modos, feliz edición. Anythingyouwant ( discusión ) 14:08 13 may 2015 (UTC) [ responder ]
Elecciones de ArbCom 2016¡La votación ya está abierta!
Hola, Replysixty. La votación para las elecciones del Comité de Arbitraje de 2016 está abierta desde el lunes 21 de noviembre a las 00:00 hasta el domingo 4 de diciembre a las 23:59 para todos los usuarios desbloqueados que hayan registrado una cuenta antes del miércoles 28 de octubre de 2016 a las 00:00 y hayan realizado al menos 150 ediciones en el espacio principal antes del domingo 1 de noviembre de 2016 a las 00:00.
El Comité de Arbitraje es el panel de editores responsable de llevar a cabo el proceso de arbitraje de Wikipedia . Tiene la autoridad de imponer soluciones vinculantes a las disputas entre editores, principalmente en el caso de disputas de conducta graves que la comunidad no ha podido resolver. Esto incluye la autoridad para imponer prohibiciones de sitios , prohibiciones de temas , restricciones de edición y otras medidas necesarias para mantener nuestro entorno de edición. La política de arbitraje describe las funciones y responsabilidades del Comité con mayor detalle.
Mensaje para los votantes de la ArbCom en las elecciones de 2017
Hola, Replysixty. La votación para las elecciones del Comité de Arbitraje de 2017 está abierta hasta las 23:59 del domingo 10 de diciembre. Todos los usuarios que registraron una cuenta antes del sábado 28 de octubre de 2017, realizaron al menos 150 ediciones en el espacio principal antes del miércoles 1 de noviembre de 2017 y no están bloqueados actualmente pueden votar. Los usuarios con cuentas alternativas solo pueden votar una vez.
El Comité de Arbitraje es el panel de editores responsable de llevar a cabo el proceso de arbitraje de Wikipedia . Tiene la autoridad de imponer soluciones vinculantes a las disputas entre editores, principalmente en el caso de disputas de conducta graves que la comunidad no ha podido resolver. Esto incluye la autoridad para imponer prohibiciones de sitios , prohibiciones de temas , restricciones de edición y otras medidas necesarias para mantener nuestro entorno de edición. La política de arbitraje describe las funciones y responsabilidades del Comité con mayor detalle.
Hola. Respondí a un comentario que hiciste en la página de discusión de comunicación científica . No estoy seguro de si te notificaría automáticamente, así que pensé en dejarte una nota aquí en tu página de discusión también. Me interesa esta lista porque estoy enseñando un curso de métodos de investigación y estoy trabajando con estudiantes para comprender mejor la comunicación científica y hacer conexiones con personas de la cultura popular (medios de comunicación masivos) que ya reconocen que ayudarían en este esfuerzo. -- Djgriffin7 ( discusión ) 21:22 20 oct 2018 (UTC) [ responder ]
Mensaje para los votantes de la ArbCom en las elecciones de 2018
Hola, Replysixty. La votación para las elecciones del Comité de Arbitraje de 2018 está abierta hasta las 23:59 del domingo 3 de diciembre. Todos los usuarios que registraron una cuenta antes del domingo 28 de octubre de 2018, realizaron al menos 150 ediciones en el espacio principal antes del jueves 1 de noviembre de 2018 y no están bloqueados actualmente pueden votar. Los usuarios con cuentas alternativas solo pueden votar una vez.
El Comité de Arbitraje es el panel de editores responsable de llevar a cabo el proceso de arbitraje de Wikipedia . Tiene la autoridad de imponer soluciones vinculantes a las disputas entre editores, principalmente en el caso de disputas de conducta graves que la comunidad no ha podido resolver. Esto incluye la autoridad para imponer prohibiciones de sitios , prohibiciones de temas , restricciones de edición y otras medidas necesarias para mantener nuestro entorno de edición. La política de arbitraje describe las funciones y responsabilidades del Comité con mayor detalle.
Actualmente pareces estar involucrado en una guerra de ediciones según las reversiones que has hecho en Come as You Are (canción de Nirvana) . Ten en cuenta que la regla de las tres reversiones prohíbe hacer más de tres reversiones en una sola página en un período de 24 horas. Además, los usuarios que realicen una gran cantidad de reversiones en disputas de contenido pueden ser bloqueados por guerra de ediciones, incluso si técnicamente no violan la regla de las tres reversiones . Si continúas, es posible que se te bloquee la edición . No reviertas ediciones repetidamente, sino que usa la página de discusión para trabajar en la redacción y el contenido que obtengan un consenso entre los editores. Si es necesario, busca la resolución de la disputa . JD554 ( discusión ) 10:03, 6 de agosto de 2009 (UTC) 
Hola, soy ReferenceBot . He detectado automáticamente que una edición realizada por ti puede haber introducido errores en la referenciación. Es lo siguiente: