Forgot to include my commit on the wiki repo:
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=232e3d71124c438402d791be8d024937fbf25fd3

(In reply to Andrey Miroshnikov from comment #0)

> Started the wiki page section is called "How to raise issues" (2.2.1) 

"how" does not emphasise "why", and it is the WHY that stops resentment
at being "forced" to "waste time" on "stupid project management"

that alone is important enough to have its own section... *and then*
under that have the "actions" (the "how"s)

can you both now have a conversation on IRC
(placing links back here as you do so) recounting
your recollection of what i said on the conf. call
today?  it may take some time, it may take only minutes,
but whatever happens you will see *and experience* the
very issues that then need themselves to be documented.

i have added some additional advice especially "why"
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=9a7a107c95a0fddbb5209428fb1394ca706aa2a4

you (one of you) need to coordinate amongst yourselves to decide
who s going to document *this* practice.

see what jacob did here:
https://bugs.libre-soc.org/show_bug.cgi?id=1125#c0

it is not perfect but pretty good, i much prefer the links to
the diffs as it is quicker and easier to review.

After group call, Luke made useful comments on including milestones and budget information, so I included a few extra points in HDL_workflow.

See commit diff: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=fccae2f02cb75bf5658bd1ae983f530df630f51c

andrey shriya: https://bugs.libre-soc.org/show_bug.cgi?id=1139#c5
needs to be in the "why" and then in the "how/what"

andrey, shriya: more to be added to the "why and how"

https://libre-soc.org/irclog/%23libre-soc.2023-08-15.log.html#t2023-08-15T00:01:34

yes this is the process that i have been following for five years.
i expect everyone to know it, know *why* it exists, and follow it
strictly because the damage done, time wasted and jeapordy to the
project by failing to meet its unwritten obligations to NLnet,
is otherwise unacceptable.

(In reply to Luke Kenneth Casson Leighton from comment #5)
> needs to be in the "why" and then in the "how/what"

(In reply to Luke Kenneth Casson Leighton from comment #6)
> andrey, shriya: more to be added to the "why and how"

Added a few more lines based on your conversations:
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=9b6b662d559441a2f01d1b6cfbb88b832e617f25
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=c0b515803e2ffdb18582d9aa8336d5060fdf5526

Forgot about the two sections, so I moved the 'why' sentences to their respective place:
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=70e614970fbc51691114f36961bb3a5f2cac4620

andrey, ths also needs adding, "how to do budget estimation"
https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-August/005592.html

it involves guestimating +/- 40% a number of days where "number"
is less than appx 8, but no smaller than 1/2 a day,
and the total subtasks so estimated is appx 5-25.
if greater than 8 days it is REQUIRED to break it into
smaller subtasks.

statistically speaking the +/- 40% variance when added up
over 20+ tasks gives a time estimate that is accurate to +/- 10%.

... but you have to actually have a fricking clue and a clear
idea of what is actually needed, and NOT leave anything out.
forget to add say "do the documentation" to the list of tasks
to be estimated for funding and you just screwed the project by
failing to put in the Grant Request to cover 80% more work than
there is available money.
or your project just has no documentation and is worthless due to
noone being able to maintain it in future.

also the following need adding to the HDL_workflow along with
explanations:

* Liskov Substitution Principle
* Principle of Least Surprise

https://bugs.libre-soc.org/show_bug.cgi?id=1039#c33

always put "bug #NNN" not "#NNN".  add the insight about saving time
and making things easier to track in order to focus on accelerating
iteration.

slogging through bugs forcing developers to type "NNN" into the bug/search
field (if they even know about that), rather than just clicking on a link?
this is hostile to forward progress, and aggravating.

https://libre-soc.org/irclog/%23libre-soc.2023-08-25.log.html#t2023-08-25T10:00:05

also need to be aware of the level of inter-dependencies, the specification
being *the* absolute top priority for maintaining as "100% up-to-date",
followed by a cascade of inter-dependent bugreports that trickle down from
that to cover the CSV files, insndb, ISACaller, binutils, and then to
TestIssuer which has its own set of dependencies especially if a new
regfile or SPR is added.

https://libre-soc.org/irclog/%23libre-soc.2023-09-02.log.html#t2023-09-02T08:32:23

"do not attempt to re-use bugs" section needed. rationale here:
http://lists.libre-soc.org/pipermail/libre-soc-dev/2023-September/005625.html

all code MUST have copyright notices license headers and an NLnet
grant and EU ref number
https://bugs.libre-soc.org/show_bug.cgi?id=982#c23

extremely important.

Also link #1164 into HDL_workflow and into the main front page in
order to make it easy for people to find examples of other people
going through onboarding, and also to find a template for the same.

another necessary task, highlighted from bug #1171:
whenever new sub-tasks are added which have a sub-budget
assigned from an existing Milestone, it is necessary to:

* notify Michiel and the relevant NNNN-NN@nlnet.nl team of
  advance notice of intent to add new sub-tasks, cc'ing bob
  goudriaan 
  - confirm with them that this is NOT a change in the AGREED
    MILESTONE BUDGETs, because it is just sub-task allocation.
  - confirm that they are happy to add the sub-tasks to the MoU
    (this needs approval of bob goudriaan)
* *re-generate* the JSON file
* make a DIFF against the *PREVIOUS* JSON file
* create a MANUAL report/summary of "changes" that
  NLnet may easily action
  - "add the following task X to parent Y of amount W",
  - and if any: "change parent Z available amount to V as a WRAPUP")
  (this latter is because occasionally there are subtasks NOT
   totalling the full parent amount, usually because a summary
   report is needed. Michiel and I privately agreed to call
   this "wrapup")
* obtain a confirmation that this has been actioned
* DOUBLE-CHECK that the RFP database correctly matches the new
  bugzilla status.

PLEASE NOTE: YOU CANNOT ACTION THE ABOVE UNDER THE FOLLOWING CIRCUMSTANCES

1. to make a change to the actual budgetary amounts of the
   Grant Milestones, without written authorization from Bob
   and Michiel. a DIFFERENT PROCEDURE is needed.
   this is because NLnet had to go through a 3rd party Verification
   Process with the European Union: changing the amounts without
   consent is therefore tantamount to fraud.

2. if there has been an RFP already submitted under a given Milestone,
   it becomes NO LONGER POSSIBLE to change the JSON file in NLnet's
   system because it is too complex.

   there is one Grant in this complex situation: bug #690, the crypto
   grant.  it is made much more complex because it *pre-dates* NLnet's
   current RFP system, where RFPs were submitted by EMAIL and there
   are manual records not fully integrated into the database.

also note: as the addition of sub-tasks *requires a change to the MOU*
it should NOT be taken lightly, i.e. should not be arbitrarily done
one by one, but only in "batches".

considerable care therefore has to be taken to ensure that NLnet are
not overloaded, nor that the EU Auditor is given grounds to become
"suspicious" because of a dozen or more alterations to the MOU.

Created a new page which will be used to document points covered under this bug:
https://libre-soc.org/libresoc_bug_process/

https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=20d7aed364a29d298af4994575be259c3491f84f
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=3e6492ea4f6b4cdc8b04bc6d8b0ea9358ac4dce8

I will be gradually adding bits over the course of today.

(In reply to Andrey Miroshnikov from comment #16)
> Created a new page which will be used to document points covered under this
> bug:
> https://libre-soc.org/libresoc_bug_process/

(In reply to Luke Kenneth Casson Leighton from comment #15)
> another necessary task, highlighted from bug #1171:
> whenever new sub-tasks are added which have a sub-budget
> assigned from an existing Milestone, it is necessary to:

Added information from your comment Luke:
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=1f2f589f6f3f73b9890bd5d0c7a4ad19de96c061

Jacob please have a good read over it to familiarise yourself (I need to do so too, as well as the rest of team).

(In reply to Andrey Miroshnikov from comment #16)
> Created a new page which will be used to document points covered under this
> bug:
> https://libre-soc.org/libresoc_bug_process/

it goes under HDL_workflow

(In reply to Luke Kenneth Casson Leighton from comment #18)

> it goes under HDL_workflow

https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=f924c90239a

done. TODO: link in a section in HDL_workflow

luke asked to post the "i'm thinking of doing ..." procedure:
https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-September/005678.html

(In reply to Jacob Lifshay from comment #20)
> luke asked to post the "i'm thinking of doing ..." procedure:
> https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-September/005678.
> html

i meant, "track down the email from last week"
and track down the mailing list posts on the
same topic (when i first sent them, nearly a year
ago), and explicitly post the copy here so that it can
be put into the wiki.

i am not going to repeat it or write it out again for the
seventh time in one year 

*your* responsibility is to listen the first time.

https://bugs.libre-soc.org/show_bug.cgi?id=1083#c14

adage about 3 revisions.

(In reply to Jacob Lifshay from comment #20)
> luke asked to post the "i'm thinking of doing ..." procedure:
> https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-September/005678.
> html

jacob can you please complete this, i am assigning to you as a reminder

(In reply to Luke Kenneth Casson Leighton from comment #23)
> (In reply to Jacob Lifshay from comment #20)
> > luke asked to post the "i'm thinking of doing ..." procedure:
> > https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-September/005678.
> > html
> 
> jacob can you please complete this, i am assigning to you as a reminder

Jacob, can you please add the "i am thinking of doing X" procedure to this page:
https://libre-soc.org/HDL_workflow/libresoc_bug_process/
as a new section.

This is important for the rest of the team to know, and the sooner we get that documented, the better.

(In reply to Andrey Miroshnikov from comment #24)
> Jacob, can you please add the "i am thinking of doing X" procedure to this

Actually, apologies, change of plan.

I'll take this one on.

Jacob, you can focus on the other tasks you're assigned to.

(In reply to Andrey Miroshnikov from comment #25)
> (In reply to Andrey Miroshnikov from comment #24)
> > Jacob, can you please add the "i am thinking of doing X" procedure to this
> 
> Actually, apologies, change of plan.

Apologies, luke and andrey, I got distracted with other things and didn't get around to doing that task.

(In reply to Jacob Lifshay from comment #26)
> Apologies, luke and andrey, I got distracted with other things and didn't
> get around to doing that task.

That's fine, but please do remember to focus on the tasks for cryptorouter and cavatools grants that need to be done (unless that's what you were distracted by). The sooner we get those done, the sooner we'll be able to apply for new grants (with potentially very interesting work).


On another note, I need to add the point of having a summary comment in a completed bug (to make a clear declaration that budget is justified, and make the job easier for any potential auditors):
https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-October/005730.html

(In reply to Andrey Miroshnikov from comment #27)

> On another note, I need to add the point of having a summary comment in a
> completed bug 

well... yes and no.  if the task is obvious, no.
the way that Michiel put it is: if you *need* a long
summary, because it is useful (documentation) then do it,
but it is nothing to do with NLnet.

in other words a BRIEF maximum ONE paragraph summary,
even just one sentence, is more than enough.

but, also, if comment #0 has a TODO list and the TODO
list has all been changed to DONE, it is obviously
totally unnecessary to write pages and pages of report.

bottom line you have to be sensible here.

typically what i have done is follow ISO 9000.

* say what you are going to do (MoU Task description)
* do it                        (TODO list, comments, commits)
* say that you have done it    (close the bugreport)

now, the only reason for making even 2 paragraphs is if
you DID NOT DO THE WORK but instead did something else,
or only completed say 50%.  there you MUST provide a
SUMMARY explanation.  here is a good example:
https://bugs.libre-soc.org/show_bug.cgi?id=784#c43



> (to make a clear declaration that budget is justified, and
> make the job easier for any potential auditors):

https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-October/005731.html

(In reply to Luke Kenneth Casson Leighton from comment #2)

> can you both now have a conversation on IRC
> (placing links back here as you do so) recounting
> your recollection of what i said on the conf. call
> today?  it may take some time, it may take only minutes,
> but whatever happens you will see *and experience* the
> very issues that then need themselves to be documented.

so, Andrey: can you now remember, just over three months later,
what the contents of that verbal conversation was? can you recall
what i said? because i can't!

and did you have the conversation on IRC as i instructed? and
can you find the link easily without a lot of hassle and
searching through pages and pages of other IRC conversations?

which should hammer home precisely and exactly why i set the
project management rule that requires that the conversation
take place immediately *and be linked to the bug*.

Andrey: this is now your responsibility to ensure that everyone follows
these procedures, and the amount of hassle involved in the *retrospective*
sourcing of the information discussed three months ago should neatly hammer
home why it is necessary to follow these procedures immediately, at the
time that the conversations take place.

everyone: it is *also* your responsibility to follow these procedures
so that Andrey is not overwhelmed. it is extremely tedious to keep chasing
people, and i can tell you right now it is exhausting to keep doing for years.

(In reply to Luke Kenneth Casson Leighton from comment #29)
> so, Andrey: can you now remember, just over three months later,
> what the contents of that verbal conversation was? can you recall
> what i said? because i can't!
> 
> and did you have the conversation on IRC as i instructed? and
> can you find the link easily without a lot of hassle and
> searching through pages and pages of other IRC conversations?
> 
> which should hammer home precisely and exactly why i set the
> project management rule that requires that the conversation
> take place immediately *and be linked to the bug*.

I'm going to add the process procedure which I showed you last week, and see what else is outstanding on this bug. I apologise for not tracking it sooner.

However I will *start doing this later in the week* (there's enough to do already).

> 
> Andrey: this is now your responsibility to ensure that everyone follows
> these procedures, and the amount of hassle involved in the *retrospective*
> sourcing of the information discussed three months ago should neatly hammer
> home why it is necessary to follow these procedures immediately, at the
> time that the conversations take place.

Yes, I know that.

(In reply to Andrey Miroshnikov from comment #30)

> I'm going to add the process procedure which I showed you last week,

great. thank you. i am considering closing this bugreport, as long as
the process is written even in ths bugreport i'm good with that.

> and see
> what else is outstanding on this bug. I apologise for not tracking it sooner.

not a problem.

> However I will *start doing this later in the week* (there's enough to do
> already).

tell me about it...

> Yes, I know that.

indeed. i was mainly commenting for everyone's benefit.

Important point raised during today's meeting with Michiel, having completed CI logs of a successful test (when a bug is completed) would greatly aid the RfP auditing process.

I will document this on HDL Workflow:
- How to access CI system
- How to initiate a job to run the particular test
- How to access the logs
- (perhaps how move those logs to an archive on libre-soc.org, so that we don't rely on Jacob always having power/internet?)
- Add comment on completed bug linking to CI logs


I know there are other outstanding tasks on this bug, after this morning I'll finally have some time to focus on getting them done.

(In reply to Andrey Miroshnikov from comment #32)
> - (perhaps how move those logs to an archive on libre-soc.org, so that we
> don't rely on Jacob always having power/internet?)
> - Add comment on completed bug linking to CI logs

Maybe, attaching the completed log as a file to the bug?
Also should have instructions in case auditor wishes to confirm the results are true by running the CI themselves.



Also just remembered, a few brief instructions as to how to run the test for the completed bug included as part of the RfP process (need to think this one through).

(In reply to Andrey Miroshnikov from comment #32)
> Important point raised during today's meeting with Michiel, having completed
> CI logs of a successful test (when a bug is completed) would greatly aid the
> RfP auditing process.
> 
> I will document this on HDL Workflow:
> - How to access CI system
> - How to initiate a job to run the particular test

it's automatc, everything is run.

> - How to access the logs

jacob's server. there are examples already in the bugtracker.

> - (perhaps how move those logs to an archive on libre-soc.org, so that we
> don't rely on Jacob always having power/internet?)

noOoOoo. the VM allocation is 20 GB and costs significant money.
already explained many times why.

> - Add comment on completed bug linking to CI logs
> 
> 
> I know there are other outstanding tasks on this bug, after this morning
> I'll finally have some time to focus on getting them done.

take your time, the main key thing was to get the action noted here
immediately after the meeting.

(In reply to Andrey Miroshnikov from comment #33)
> (In reply to Andrey Miroshnikov from comment #32)
> > - (perhaps how move those logs to an archive on libre-soc.org, so that we
> > don't rely on Jacob always having power/internet?)
> > - Add comment on completed bug linking to CI logs
> 
> Maybe, attaching the completed log as a file to the bug?


NO, under no circumstances. attachments end up in the *postgres database*
which will end up running the server out of disk space in a matter
of weeks. it *only has 20 GB* for very good reasons, discussed and
explained many times.

however doing a *mirror* onto backed-up secondary storage of those
very same log files, i have no problem with that whatsoever.

the server *has* to stay lean and basic otherwise i cannot back it
up over a mobile internet connection, plus it costs a hell of a lot
of money due to the reliability and service guarantees.

> Also should have instructions in case auditor wishes to confirm the results
> are true by running the CI themselves.

... or the team in lisbon that michiel mentioned, or nlnet themselves.
 

> Also just remembered, a few brief instructions as to how to run the test for
> the completed bug included as part of the RfP process (need to think this
> one through).

oh yes. that is just "what people write in the report". if the online
CI logs have a line-number hash (like gitweb "...../#L540") then
that will do

Started tackling the backlog of documentation.

(In reply to Luke Kenneth Casson Leighton from comment #8)
> andrey, ths also needs adding, "how to do budget estimation"
> https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-August/005592.html
Done:
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=5dd494cd1e30d3b47435ce32e93a701b80ee9daf

(In reply to Luke Kenneth Casson Leighton from comment #9)
> * Liskov Substitution Principle
> * Principle of Least Surprise
Added both entries:
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=feafa6e020ad0a7d0d2331ca2a1a806262c86eba

see https://bugs.libre-soc.org/show_bug.cgi?id=1177#c25

(In reply to Andrey Miroshnikov from comment #35)
> Started tackling the backlog of documentation.

hmmm just a thought, these are actually better done as TODO/DONE in comment #0
otherwise new additions mix in with completed ones.

plus: how do you know which ones are done and which are not?

Finally got around to documenting the "I'm doing..." procedure, see here:
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=09d4356bdc5775c5e136b2760a584a159efb7aaf
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=583a0852053dde49ffadf56f629729c3fada3228

https://libre-soc.org/HDL_workflow/libresoc_bug_process/


(In reply to Luke Kenneth Casson Leighton from comment #37)
> hmmm just a thought, these are actually better done as TODO/DONE in comment
> #0
> otherwise new additions mix in with completed ones.
Modified comment #0.

> 
> plus: how do you know which ones are done and which are not?
Read the comment history hahaha (yes, I know, this is unsustainable, which is why I followed your suggestion).

meeting minutes procedure and practices
https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-November/005797.html

I suggest we stick to some simple rules upon formatting git commits:

1. Every commit MUST start with a short title, up to 50 characters.
2. The coomit title MUST contain either subsystem, or a file path, or a subsystem/path, or a subsystem/subsubsystem combination, which got modified or introduced, and a short summary. These parts must be separated by the semicolon.
3. A good rule is to imagine that the short message begins with "if this patch is applied, it will". For example, a good title is "X: update Y", not "updated Y in X".
4. After the title, there must be an empty line, which documents the changes. The limit is 72 characters per line.
5. The long description can be omitted if the short description provides enough information or if the commit itself is simple enough.


subsystem/file.py: document usage

Here goes the long description, which explains everything. First of all,
we stick to limit of 72 characters. Then, perhaps, we'd like to explain
the rationale in more details.


I'd suggest to just stick to common sense whenever we choose subsystem names or files or long descriptions. My primary concerns are: 1) short titles; 2) short summaries; 3) wording for the first line. The rest is up for the committers.

Updated multiple sections:

https://bugs.libre-soc.org/show_bug.cgi?id=1126#c40
Added git commit message format (comment #40), thanks for the explanation Dmitry!
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=2e4797ddd674b3df95320a4bb010bc2834b02308
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=7b793f3878f317c1d72d10887f743abb3ccb2b8d

Bug #NNN reference (comment #10)
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=4da2c9b692c86e0c50e08528b91533b07a8df831

Bug re-use (c#12)
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=7bc964df3fce99c42f0a45f580543c7b9503b887

Copyright notice info (comment #13)
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=c9170c9bb0e1a7c03337cfbb2cceddb3a0c5024d

Don't include name in branch names (comment #36)
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=a2d3976da773e11a22fb1e44f4828678f44860ec

Additional topics to document:
- RfP submission process. Context:
https://bugs.libre-soc.org/show_bug.cgi?id=701#c20
https://bugs.libre-soc.org/show_bug.cgi?id=1169#c58
https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-December/005829.html

(In reply to Dmitry Selyutin from comment #40)
> 2. The coomit title MUST contain either subsystem, or a file path, or a
> subsystem/path, or a subsystem/subsubsystem combination, which got modified
> or introduced, and a short summary. These parts must be separated by the
> semicolon.

I think you meant colon `:` instead of semicolon `;` since that's what you use below:
> 
> subsystem/file.py: document usage

(In reply to Jacob Lifshay from comment #42)
> I think you meant colon `:` instead of semicolon `;` since that's what you
> use below:
> > 
> > subsystem/file.py: document usage
Thanks for spotting this Jacob.

Now fixed in the documentation:
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=9e8c69b153a40206963ec6a22729726945d6d84c

Started writing the RfP submission guide doc:
https://libre-soc.org/HDL_workflow/rfp_submission_guide/

(This page is very much a in-progress, just wanted to commit what was already in my head)

Luke, do you know if we're allowed to take a partial screenshot of the NLnet RfP submission system (removing any private information or URLs)?

(In reply to Andrey Miroshnikov from comment #44)
> Started writing the RfP submission guide doc:
> https://libre-soc.org/HDL_workflow/rfp_submission_guide/
> 
> (This page is very much a in-progress, just wanted to commit what was
> already in my head)

really good progress, good practice to follow, using the bugtracker as
a memory-substitute maes life easier but also allows collaboration and
review.

> Luke, do you know if we're allowed to take a partial screenshot of the NLnet
> RfP submission system (removing any private information or URLs)?

i don't see why not, it's a good idea. to emphasise again (in writing
not a verbal un-audited private call) it is absolutely imperative that
the secret URLs be kept secret. under no circumstances must they go onto
publicly-archived libre-soc resources: not the bugtracker, not the mailing
list, not IRC.

in other words they must be treated as the PLAIN TEXT PASSWORDS that they are,
and appropriate measures taken to protect them from leakage onto the internet
at large.

i also require that a procedure for notifying NLnet and myself be written and
documented so that NLnet can immediately *FREEZE* the RFP system to prevent
fraudulent RFPs in the event of someone publishing the plaintext
passwords / URLs.

actually it would be good to have a "canary" button, which we can activate
ourselves rather than have to wait for NLnet. can you raise that as a bugreport
and link to this comment? i will then assign it to NLnet.

(p.s. i think tnis bugreport has gone on long enough for the $, let's
close it, RFP it, and continue on a new one. the process jacob
came up with is to chnge TODO (comment #0) to "MOVED TO bug #Nnnn"
and we can put that bug into one of the new grants)

(In reply to Andrey Miroshnikov from comment #0)

> * DONE Document the procedure of raising when considering issue/improvement
> etc. ('i'm thinking of doing... procedure', have written down on paper, need
> to type up), c#20-21,c#23-25,c#30

don't shortcut these, because bugzilla creates "links"
but not on c#NN format

i have edited several, if you can complete the rest.

(In reply to Luke Kenneth Casson Leighton from comment #45)
> i also require that a procedure for notifying NLnet and myself be written and
> documented so that NLnet can immediately *FREEZE* the RFP system to prevent
> fraudulent RFPs in the event of someone publishing the plaintext
> passwords / URLs.
Added in bug #1233.

> 
> actually it would be good to have a "canary" button, which we can activate
> ourselves rather than have to wait for NLnet. can you raise that as a
> bugreport
> and link to this comment? i will then assign it to NLnet.
Bug #1232


(In reply to Luke Kenneth Casson Leighton from comment #46)
> (p.s. i think tnis bugreport has gone on long enough for the $, let's
> close it, RFP it, and continue on a new one. the process jacob
> came up with is to chnge TODO (comment #0) to "MOVED TO bug #Nnnn"
> and we can put that bug into one of the new grants)
Bug #1233 created.
Comment #0 updated.

(In reply to Andrey Miroshnikov from comment #48)
> (In reply to Luke Kenneth Casson Leighton from comment #45)

> Added in bug #1233.

ok great, i arbitrarily put that as a blocker on bug #1211, the "expansion"
grant application.

> > and link to this comment? i will then assign it to NLnet.
> Bug #1232

fantastic i have assigned it to 2022-08E@nlnet.nl, they
will now receive change-notices

> Bug #1233 created.
> Comment #0 updated.

brilliant.

(In reply to Dmitry Selyutin from comment #40)
> I suggest we stick to some simple rules upon formatting git commits:
> 
> 1. Every commit MUST start with a short title, up to 50 characters.
> 2. The coomit title MUST contain either subsystem, or a file path, or a
> subsystem/path, or a subsystem/subsubsystem combination, which got modified
> or introduced, 

risk: "added file X. changed file Y". the commit diff shows you
precisely and exactly that. it is considered bad practice.

better: bugNum: summary.

if people are not referring to the actual bug for context we have a
serious problem.

in any series of commits i tend to make sure one of them has the
full bugrport URL. it generally depends on how important the change
is as to whether i put the full URL or not

(In reply to Luke Kenneth Casson Leighton from comment #50)
> 
> risk: "added file X. changed file Y". the commit diff shows you
> precisely and exactly that. it is considered bad practice.
> 
> better: bugNum: summary.
> 

Let me disagree. Not all issues refer to an actual bug. I agree this is a good information to have, but not in the title, rather in the description. As for changes on multiple files, that's exactly why I tend to use subsystem's name, not the files. We generally modify the subsystem's behaviour, not just modify random files.

> if people are not referring to the actual bug for context we have a
> serious problem.
> 
> in any series of commits i tend to make sure one of them has the
> full bugrport URL. it generally depends on how important the change
> is as to whether i put the full URL or not

We might opt to introduce a git hook which mandates this based on some conditions, e.g. when there are too many changed lines. But generally I'd avoid enforcing this everywhere, some fixes might be trivial or drive-by ones.


After all, commiting is about a commitment, people should enjoy doing this. If we impose too strict guidelines, this would simply freak out the contributors.