Hi Denis Le mar. 7 janv. 2020 à 06:24, Denis Rouzaud <denis.rouz...@gmail.com> a écrit :
> Hi Harrissou, > > No worries, I have been more focused on technical matters up to now, but I > was indeed expecting some room for improvements. There was a bit of a > stress to provide reports for the grant proposal, but it was clearly a call > for discussion, sorry not to state it clearly. > > Merci, Harrissou (follow-up in Matthias message) > > Le mar. 7 janv. 2020 à 02:59, DelazJ <del...@gmail.com> a écrit : > >> Hi all, >> >> Thanks Denis for the work. >> I might be missing some key points because comparing the generated >> reports from the two systems, I'm sorry I feel like it's instead a >> regression. Alow me to explain: >> >> 1. For the same feature merged in the code, see old system report [0] vs >> new system's [1]. From a doc writer perspective, I get more information >> from the first one than the second. >> > > I see. So following Nyall's suggestion: > 1. Copy description > 2. Copy commit message of commits having [needs-doc] (similarly to now) > >> >> 2. Another point is that milestone is what we use to filter issues >> reports and manage the docs schedule, so if it's not set by the developer >> (assuming that the dev knows the milestone to indicate), someone has to do >> it manually in the generated report. With the current system, when we enter >> a new development cycle, we (Richard and myself) set the new milestone (for >> LTR) and the target version label [2] and then, every generated report is >> automatically filled with these information at their creation. Done once >> and nobody cares about anymore. Until the next release. >> This new system means devs "should" enter that information for each >> doc-related PR. I can't count the number of times I made a remind for the >> [needs-docs] label, and the PR was merged without... >> > > I see. > So, you take the assumption that any request for documentation happens in > the current release and not in the past. > I guess it might make sense and that it would still be possible to handle > manually the case. > I will see if I can do some nice grepping of the CMakeLists (or as > Matthias suggested max(release-x_y)+2 ) to calculate labels and milestone. > >> >> 3. What is meant by "developers should take care of it"? When/where will >> the details of the feature be available? If the dev wants to write about >> his changes in our docs, OK. Otherwise, are we not overloading their >> workload while they could have provided the necessary bits in the commit >> message, as they should be doing currently. >> What I understood from the proposal is that developers will be encouraged >> to detail their feature in the PR message, the place they sell their >> feature to others, using a simple and accessible language. And then, at the >> merge time, the message of the PR (with maybe screenshots) will be copied >> to the generated report in docs, allowing writers to see what the feature >> is. Did I misunderstand or have the options changed meanwhile? >> > > I will update the message explaining how the bot works and that the PR > author should document in the description. > And there, if you have any improvement to make as text changes feel free > to go ahead. > > Denis >> >
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer