Lines Matching refs:qu

155 y/o para explicar por qué el código hace lo que hace. No reitere lo que el
248 información debe ser fácil de encontrar. Changelogs que entierran el "qué
256 inútiles, los detalles sólo importan para el culpable. Proporcionar el "qué
260 Otra ventaja de decir primero "qué cambia" es que casi siempre es posible
261 decir "qué cambia" en una sola frase. A la inversa, todo menos los errores
263 Si tanto "qué está cambiando" como "cuál es el fallo" son muy breves, el
264 orden no importa. Pero si uno es más corto (casi siempre el "qué está
323 hardware, indique claramente qué nivel de pruebas ha podido realizar, por
351 qué tipo de feedback se solicita/espera. No abuse del proceso de RFC; las
359 compilación y fallos de prueba, pero debe quedar claro para lectores qué es
394 que condujeron al parche. El contexto de por qué se hizo un cambio es muy
446 notificación explicando por qué se ha retirado el parche, así como los