spec #1
Comments
|
The first question I get asked when requesting a code review is 'What are you trying to do?'. You should add a description field when creating code review, it will be easier for reviewers to quickly decide if they want to review it rather than visiting the github and scanning the (potentially useless) README. |
|
Maybe adding a category to classify the different type of goals for the code review. On the other hand, the categorization should be more broad than the examples given above. A good addition would be a more opinionated form when creating the code review request and its description. It should follow some template that would help the user give better info about its goal. There could even be different templates for each category of request. That would help avoid common descriptions like "Help! Everything is wrong!" ;) The same can be done for the final rating by the requester. A rating more semantically rich would give much more info to future requester. As for the regex used in the github url, i think it is not necessary. Github has a graphql API that could be used to check the validity of the url. For the code review, an advanced feature could be a chat channel associated for each one or one could use just the format of a forum, where the code review page would be like a thread with posts. |
|
@Remulos great idea, I'll add that as a field in the form
|
I think a better rating workflow should be based on what browsing requester are interested to know. Here are some potential ideas to seed the structure of the rating, but they should be better reviewed in the future (also there shouldn't be to much of them, just enough to give a good idea):
Of course not forgetting a comment field. The spoken language could be also a feature. That would give the possibility to join people with native language other than english. This does not mean a multi-language app. The app's official language could still be only english. From all of this, an interesting feature arise. The users would have Projects/Repos as atomic objects and each projects could have different requests. This is a natural occurrence, if for example, i had a request today for the same project where other requests have already been solved. This is only in the point of view of the requester. The implementation shouldn't be to different from just using requests. |
Just wanted to mention this, maybe allow gists too. |
|
One requester could put its request as simply public, but he could also add specific code reviewers by name. Those reviewers would then get a notification of a request to review. This brings the necessity to facilitate the access to the reviews of an user. Which bring a Profile page for each of them, where, beside the reviews given to them, they could put a brief bio, foto, avatar, companhy logo and url, other usual contact info... One other feature would be to give the possibility to code reviewers to also rate their interaction with the requester. This would help future users to decide if they want to accept the request or avoid waste of time, inter-personal head-heck or simple trolling. One other thing that the spec are missing is an admin section of the app and a help-desk/issue system. |
This is increasingly sounding like a niche clone of fiverr or Upwork. |
I am only adding thing, taking in mind a full fledged app, but i do not know the vision that @benawad has for this app. He will be the final deciding factor in everything. Nonetheless most of the features that he decide to add will certainly be divided in different phases of the app. The main goal should be to have a 1º usable version with minimum usability. |
They are singing in with GitHub which contains most of those + open source contributions and personal projects. |
That is an excellent point. Github has a wealth of info that could be used and reorganized automatically to give a better profile and doesn't have to be in the app database. |
|
Consider taking a look at Gitpod. It's not like Codeponder in essence, but they both integrate with GitHub in a pretty integral way. Gitpod is basically a VS Code like experience for any GitHub repo, and the way you open it up is: WDYT? |
One would have to change the business model.
As for monetization, this is good read: What is Stack Overflow's business model?
|
|
I think I like that business model better |
|
This might not be the best place to put this comment, but it involves several random ideas and i do not see the necessity to open new issues. And it does have some relevance to decide the specs... I have seen your new video and i do like your idea. You probably will have much more work to do, but i have no doubt that it will be rewarding. Here are some things that may help:
{
repository(name: "codeponder", owner: "benawad") {
object(expression: "master:packages/server/src/index.ts") {
... on Blob {
text
oid
}
}
}
}
{
repository(name: "codeponder", owner: "benawad") {
object(expression: "master:") {
... on Tree {
entries {
name
type
object {
... on Blob {
text
}
... on Tree {
entries {
name
type
object {
... on Blob {
text
}
}
}
}
}
}
}
}
}
}
{
user(login: "benawad") {
avatarUrl
bio
company
email
gists(first: 5, orderBy: {field: CREATED_AT, direction: ASC}) {
edges {
node {
... on Gist {
id
}
id
description
name
}
}
totalCount
}
}
}One thing to note is that a user do not have to get any special permission to access common data from other users |
|
@audiBookning I see using the graphql api to get metadata on the repo, but is that the best way to get the code? We want all the files, so we would need a way to request all the levels. I'm thinking maybe we get it by downloading the zip, but I'm not sure if there's a better way. |
I was under the impression that the app would only request the files that it need for the review and save only references to them. The server would only manage the comments and the files would maybe only be fetched by the user's browser. This would avoid the storage and management all of them and adding a much greater weight to the server. Also the fact that the users browser is the one that makes the request to github, would also avoid some possible problems with rate limiting from github (not sure about this). To achieve the storage of all the files, the graphql API doesn't seem the better option. It seems to me that the best would be to either have git installed on the server or just use a package like NodeGit Another alternative would be to not reinvent the wheel and use an editor that already has all of those features. I mentioned monaco editor, but it has only basic features. Fortunately CodeSandbox is a much more advanced editor based on monaco that is very similar in its features to Gitpod mentioned earlier also and seem to have many others. Better yet, it has a github repo and is GNU General Public License. Some small adaptation and filtering would probably necessary. Or one could simply use it as a source of inspiration. There are others package with interest:
|
This is taken from the GitHub API Documentation:
Also, Wcode looks good, I might have to try using it myself! |
|
Rate limiting :(
You should look at CodeSandbox, it has all of wcode features and much more. The problem is that for simples things it may have too much and be too complicated. |
|
I'm thinking of taking a snapshot of the code from GitHub and storing it on something like s3. Then I don't have to worry about the rate limit and the code will never change this way. |
Unless you want to convince people to use your git service, you may have to maintain the code in sync with the origin. Github has Webhooks that would help in that. If you use them, it might a bit unrealistic to sync every time a webhook is triggered. Imagine the case of one person heavily and constantly pushing to origin. This behavior multiplied by many users would be bad for the app (big traffic in an app is also great news!). |
|
@audiBookning the questions are only relevant to the original versions of code so I don't see why would you constantly sync it? If someone completely changes a file the question would lose all it's meaning plus it would be hard to keep "flagged" lines of code in sync with the actual code. |
|
@sterjoski I may not be visualizing correctly the app, but consider this argument. You are right if the question posed by the review is a simple one. But solving a minimally complex problem is normally a process with different iterations. worse if there is some misunderstanding in the communication. The app should be able to stay relevant with the latest changes in the code.
Yes that will be one of the greater obstacles that the app will have to surmount (even without the added sync). A feature to diff the versions of the files seem to be a must to deal with this... That might be also the way to 'flag' the lines of codes and maintain a good enough reference to 'position' the comments? |
|
I see it as something that doesn't know about the git history and if you want to rework the code and get a second review then you can make another post. If you want to do many iterations pick GitHub or another tools. |
That is fair :) |
|
So the preferred workflow would be to take a snapshot of the files when the review request is created, store those files (essentially the up-to-date repo minus the git history) on your server, have reviewers edit or comment code in an browser editor (like code CodeSandbox or Wcode) and then push those changes to the repo once the review is complete, once the review is completed, each party can rate the other to some degree or another on a variety of topics (professionalism, quality of comments, standard of code, etc.). |
I'm thinking the reviewers can write comments, but not edit the code. |
Since there is a comment section the author and the reviewers can go back and forth on implementing a specific code snippet or whatever. Make the comments support Markdown and add Prism and you are all set. |
If there is no code editing, that would be much simpler to implement. |
this is the better way of doing this, but the disadvantage is it need separate architecture for managing massive code base data in your s3, bucket , add some corn jobs for cleaning after review is closed. |
|
guys please check this opensource project for live interactive code IDE on browser easy for expert debug there code in browser at any place. and they just need to hook the github repo link with IDE |
|
To avoid storing things at first, I'm thinking of forking the repo to "snapshot" it and then make all the requests through github's api and then if this get's popular enough that we run into rate limit problems, then move it to s3. |
|
I have found some good sources for inspiration. Maybe some of them can be useful with different strategies to deal with the github repos:
I hope it helps. |
|
Definitely some good ideas here, i wanted to make my contribution and highlight the ideas which i like. Single page for each repo, various request pages per repo: Company/startups profiles: I also wanted to accentuate the references to adding webhooks and a live code editor to the application; while definitely good, they may place a sizable weight on the first version of the app.
One idea is to store certain files to be reviewed where the main logic is and then link to the github repo for dependencies/utilities. For the feature of repos adding to be reviewed i'd really like to emulate the Netlify experience, if anyone has tried it, it is really straight-forward, you connect through OAuth, select the repo, and deploy (request a review). Finally i wanted to have the possibility to have more than just 3 tags for the main programming languages, i'd like people to be able to sort not only by programming languages but by libraries as well so also people knowledgeable of those libraries or even maintainers/contributors could review code; so instead of 'React, Typescript, GraphQL' we could have 'Typegrahqpl, Typeorm, etc...". |
Yes. Although i shared many of the code editor links, i am becoming more and more certain (just sharing my opinion) that it isn't, at this time (and even maybe for much more advanced versions of the app), a good path to pursue, not only for the type of application that Ben seem to envision but also for many similar to it. And that is for many reasons, including weight and complexity not only for the code, but also for the UX part. It will probably confuse too much the workflow of the reviewing process without adding real value to balance the steeper access and learning slope to the functionalities of the app. One could argue that, in an advanced version of the project (who knows what the future entails...), if the app had a feature to transform the edited code in pull request, that it may have more value. But, as Ben mentioned before, it would only be needlessly recreating Github. One must not forget that most developers already have setup a trusted workflow and tools to code and share that code. The main goal of a reviewing application shouldn't be to replace them. Worse is, as it would smear the core of the business model like one in the lines of stackoverflow (as mentioned on a previous post) and many others business models. Although the markdown approach or a similar simple one for quick and dirty code reviews should be considered. |
RenovateBot: change config from ignoreDeps to followTag for React Hooks
Marketplace for Code Reviews
The text was updated successfully, but these errors were encountered: