Task priorities and claiming.

[ni4]

Description

Hi all. For a while I was thinking about changing development process a bit to make it somehow more organized and structured. So my proposal of workflow is as following:

• I will describe current priorities in this or similar issues periodically (or upon request, if some clarification is needed or we went out of priorities :)
• All questions and suggestions regarding the priorities are welcome, of course.
• Developers, knowing the priorities, will pick preferred issues, and ask about it in the issue comments.
• Once approved, issue is assigned to the developer so now he is responsible for task completion.
• Another way of assigning the issue is asking the developers in issue comments.

@ronaldtse What do you think about such process? cc @dewyatt @rrrooommmaaa @joke325

[ni4]

Priorities: May, 2020

Till the end of the May we need to make release build with features asked by TB team. My view of priorities is as following:

So the following will be in priority:

• FFI interface for signature stripping (I started work on this already)
• issues regarding key/signatures edge cases. Since I did a lot of work in this direction most of them I'll claim for me.
• security issues
• issues with Windows compatibility (we need to make CI running well again)
• other issues reported by TB team.
• tests for edge cases on FFI level

Things which are out of priority:

• refactoring (unless it make impact on performance/security)
• new CLI features and tests
• new heavy OpenPGP features unless got some incompatibility with other implementation

[antonsviridenko]

by TB team.

What is TB in this context?

[ni4]

@antonsviridenko Mozilla Thunderbird, RNP will be used there since the next major release.

[dewyatt]

This sounds a tad dictatorial to be perfectly honest

[ni4]

@dewyatt Maybe I picked wrong words. Basically, I'd like to have a bit more organized approach to the process, so we move in a single direction, and move a bit faster. Say, some time limits for PR reviews, some discussion before task picking, whatever else. Does this make sense?

[rrrooommmaaa]

@ni4 The suggested process seems sensible to me

[dewyatt]

@dewyatt Maybe I picked wrong words. Basically, I'd like to have a bit more organized approach to the process, so we move in a single direction, and move a bit faster. Say, some time limits for PR reviews, some discussion before task picking, whatever else. Does this make sense?

All this sounds good, but if we have a single developer determining priorities and doing issue assignments then that is more of a lead developer. I don't have any issue with that but if we're going that route then we ought to be clearer about it and update the Reviewers and Responsibility areas section, etc.

[ni4]

All this sounds good, but if we have a single developer determining priorities and doing issue assignments then that is more of a lead developer. I don't have any issue with that but if we're going that route then we ought to be clearer about it and update the Reviewers and Responsibility areas section, etc.

Looks like it was really wrong wording from my side. That's not about determining priorities strictly by single person and telling everyone what to do but providing information/first view and initiating discussion about priorities and assignments by single person, letting others to argue/share their opinions/tell that this is bullshit and so on.

[ni4]

Btw, Reviewers/Responsibility areas sections should be updated anyway since a bunch of records there are outdated.

[ronaldtse]

@rnpgp/developers We discussed this offline and the major concern was that we needed to support our major users like Thunderbird with more transparency and better planning. I just told @ni4 to write up something.

The wording is not ideal -- but it serves as something we can work on.

I think WE need to come up with a roadmap collectively and adhere to it moving on. Due to the current situation around the world we are also having uncertainties on how we achieve certain things. Can we work together on this?

[ronaldtse]

Closing this ticket in favor of a new one.