Recommendation for the improvement of the course, explicitly label the difference between the project and the raft paper

[xhnhill]

It seems some parts of the implementation differ from the original raft paper. Maybe we could put it into an explicit position.
like the case mentioned below. It has been discussed in many places according to my search, from the content of the forum and the discussion group on the wechat.
In the doc of project2, it said If a candidate receives majority of votes of denials, it reverts back to follower.
My question is why it is designed like this? It differs from the cases mentioned in the original paper. Some people on the raft dev group said this implementation accelerates the election progress. I am curious if it is the same design intent behind tinkyKV. Clarifying this point in the README part maybe helpful to learners.
In TestLeaderElectionOverwriteNewerLogs2AB, it seems that node 1 should be candidate, not follower. According to the paper, there are three cases that candidates should give up its position. But here, node 1 just received majority of rejects, it should wait for the timeout and propose another election later.
So in the following, the wanted state should be candidate.

// Node 1 campaigns. The election fails because a quorum of nodes
// know about the election that already happened at term 2. Node 1's
// term is pushed ahead to 2.
n.send(pb.Message{From: 1, To: 1, MsgType: pb.MessageType_MsgHup})
sm1 := n.peers[1].(*Raft)
if sm1.State != StateFollower {
	t.Errorf("state = %s, want StateFollower", sm1.State)
}
if sm1.Term != 2 {
	t.Errorf("term = %d, want 2", sm1.Term)
}