gig/exercise (paid gig contract chat logs) concept & design #56
Comments
serapath
changed the title
serapath
changed the title
|
worklog 2022.06.14 8:28PM
|
|
feedback
👍 yes, add the new tasks as described in your worklog comment 👍 regarding all the things you share about the concept in your worklog videos I recorded a little feedback video regarding the structure of the UI/UX and that we have plans to make it more messenger/chat like ...all of it :-) Essentially we need to merge
see: https://share.vidyard.com/watch/bu2HV3HW1X4byxmL1i5jMs? |
|
|
feedback
hm, i would not frame the question like that. think about it as ... we are making a tool (not just for us)
the "orderer" can close the "gig ad" at any time i'd say once they found enough viable candidates
i see your diagram, but ...i think this should be expressed in wireframes of an example conversation and how the screen transitions and how do people use the chat input bar on the bottom of the chat to create specific kind of chat messages that the other side can accept to get to contractual agreements instead of just informal text |
|
Suggestion
optional: In between clicking the apply button, we could allow them to attach resume or link, before acceptance.
|
|
|
feedback
wonderful. One thing upfront about the wireframes ... it is all just rough boxes with no labels at all. otherwise: feedback for your worklog video
Ok, this was now quite a lot of feedback, but one thing i would like to add that wasnt yet mentioned in your wireframes :-) When anyone applies for a task, that task can be a single quiz question, but it could also be a giant project, so usually it is something in between, but it means when i work and talk about one or a few related tasks, like we do here in this github issue about the gig/exercise web component, then we can have a chat and have worklogs, but we should not forget, that this specific github issue chat here is only about one task in the project called:
Now - all it means is, that you could imagine this github issue more like a discord thread if you have seen those. => there needs to be a way to go "one level up" or "back" to see the parent task or issue Basically a user, a task author or contractor should be able to navigate out of one particular chat into other chats (which means other issues) of the same project where other chat discussion, like github comments, is happening - does that make sense? Now again - this should not be complicated, but should be as minimalistic as possible.
...we are building tools for programmers who use developer tools and terminals all day long, so the tools we are building should be more in that mindset and not big buttons and large menus like for end user apps :-) |
|
|
feedback
sweet.
general feedbackThis is soooooo much, si this feedback will be endless but i will split it into multiple parts. Your video is 27 minutes long, so therefore this will be a lot of feedback. I think maybe if we bounce more instead of no feedback for a long time and then a lot if input, it would be better, because you would be able to only make 3-5 minute videos and my feedback would also be shorter :-) otherwise... Ok, i am watching your video and I still think we still didn't manage to entirely understand each other. I think the overall figma template has all that default figma stuff we don't need and should delete. for example: On most screens you show this, but none of the visual elements has an icon or text yet.
can you change that for the next time? feedback 0
|
feedback 10
|
|
feedback a quick extra thought. because all worklog comments produces should reference which exact tasks you have been working on and so those tasks need to be created from the feedback i give and you can ❓ plan the outputs you are going to produce, which at the moment is probably mostly wireframes :-) i got some additional inspiration from working every day. there might be some conversation about a task in a chat like fashio like what we do here ....and there is alwasy a bunch of messages in between one and the next worklog, including all the feedback i give, so maybe ... those messages should "fold" or "collapse" into one worklog entry that is expandable ...to see those again. ...its all the chatting that happens in between one worklog video and the next? This way somebody scrolling through the issue comments can see worklog after worklog and the outputs, but they can expand the chatting and feedback between worklogs to see details ...otherwise its is A LOT :-) Ok - just wanted to share that, i will now continue with the remaining feedback in the following comments |
|
feedback feedback 20
|
|
Suggestion
I understand all that is said in the general feedback, and I'll put them into consideration in the next designs...Regarding the Lorem text... I strongly suggest it stays because It's there to tell any designer that content is going to be there unless you want me to use boxes that would be tough to understand else if no dummy text or box, it becomes empty which would be harder to understand unless explained. The same applies to the "Marketplace "---at some point the bot is going to have a name even if it's "BOT" or a "BOT tag" perhaps if it's not decided yet, we give it a dummy text so we know that place holds a text. |
|
worklog 2022.06.29
|
|
feedback
and then a user would click the button on the bottom of the screen to select an action, like create new task/project/exercise/proposal :-)
We need to think about the upper part of that chat should
One more thing: While going through those steps, the place where the And on top of the screen there could be a little
|
|
feedback
technically they are all the same, so it doesn't even really matter, but i would not make now also And if a user selects the type, the type can be shown in the preview card on top of the screen, but the next step in the form now only asks for the "descriptive name" of the task I don't think we need also "description",let's remove that. Again - payment - like mentioned above - should be about estimating time resources :-) And the bottom button is the input bar with a next/send button at the end :-)
Keep in mind, every sub todo might eventually also be its own sub chat room. So - the task card preview on top should probably show all those tasks in some sort of "file explorer preview" similar to the video i linked in my previous feedback comment. Otherwise, the inputs/outputs is cool but even the initial task before adding any sub todos, should already have the option to add inputs/outputs too Just keep in mind that should be added from the bottom input field, where you could select it as an action in that step of the form steps using maybe a This But all the actions should always be triggered from the bottom command "chat" input field bar :-) We might also want another ..but no hashtag, because the task itself should be that and the rest can be later inferred from the file name or the file ending, etc... let's keep it simple for now. Adding an input/output later on will automatically figure out from which message in which task chat room it came |
|
feedback
So that is the thing that should be shown as a collapsed summary in the task room topic bar on top of the screen or expanded as a task summary card with exactly this information. The buttons proceed/skip/add_todo should be actions in the bottom input field action bar.
otherwise i agree with stuff :-)
there is no limit to how many sub levels are possible A task who's output becomes input in 2 or more other tasks is technically a sub tasks of BOTH of those follow up task and not just one, this is why i talked about "linking" a task similar to how you can "link" a file or folder in your filesystem in more than one place. now expanding/collapsing the different tasks and sub tasks is great. More than that i would say a user can always create a task for themselves, for example a task called But doing it this way means any user is flexible to use the tool the way they want instead of us deciding that there will always be a "quick task/exercise" category ...let users make it if they want to and otherwise it is all just a single long list with sub items and sub sub items :-) You say again: anyone can just come and create a task without the need to create a project So let's just say at any time, any task can get as many sub task levels as a user wants and a task with no "parent super task" ...you call it a project ... can technically later become a subtask of a new project, when the new project uses the outputs of an old project as inputs ...so that is why it makes no sense to make the distinction so strict. everything is a task ...a project can be a single task with no sub tasks at all or it can be endlessly complex I like how the THIS IS COOL
PERFECT... 🤩
❤️❤️❤️ i love the icon for task list menu :-) |
|
feedback
Just wanted to quickly repeat some of the actions we might need.
**So this shows we need to later make wireframes where the task chat room is shown (maybe with different colors) to indicate which role is using it. is it task author or contractor? As said earlier. The form and everything is technically correct, but the style is not. So this should all be done in form steps based on the selected action in the bottom action input bar and while adding inputs/outputs/etc... the summary card in the topic channel on top should slowly show the preview ....that way we have the same result as shown in this screenshot, but its a different more consistent style. all said before - invite preview box is cool, but name and that its an invite description should be part of the card box. and the remaining part of the screenshot is something a person can explore before clicking for example
one more thing about the "overview" over the task list. Also, ...i think once you have let's say 3 people who clicked apply ...how does the interaction with those candidates look like before a candidate gets choosen? It is cool that a candidate can be "assigned", but if a task has lots of sub tasks and 3 people apply, maybe all of them can be accepted but they get assigned to different sub tasks :-) ...that is what i in the end did with you and helenphina and even joshua alexander, even though he never showed up in the end :P Also we do not have yet any wireframes for when somebody wants to "fund" a particular task |
|
worklog 2022.07.17
|
Ok, watched your videos and also after some discussion on discord, i thought i give feedback here, but i try in screencast format |
|
cool, first impresion - looks great :-)
...but if that is possible, i definitely like how clean it looks even though it has no lines :-) I was also thinking, maybe we need the 📤 and 📥 as an icone that toggles from 📤 to 📥 when you click it and indicates "expanded" or "collapsed" - in general, every icon we use should indicate something. There are plenty of emojis we can use :-) Cool thing with emojis is, that this makes sure it will work in a terminal too later on, because many developers work exclusively in the terminal it is definitely a bonus if the UI works in a terminal too :-)
We can then slowly start refining that "scenario" and the "interactive prototype" to include all the features we need based on some sort of work for an imaginary project. So if i compare your project structure with this example structure above, i think it would be better to adapt things.
...but in your example they are not
...but it doesnt make much sense to me.
Maybe this is why an "interactive figma prototype" would make sense. I feel with the chat and the action bar and the task tree menu, we really have the major building blocks to maybe try. the bright and faded arrows to open/collapse the tree is a good idea. it definitely works and makes it lighter on the eye. awesome. ...too bad those arrows don't seem to exist as emojis. at least there are some unicode characters like the ones above and then again even terminals support colors, including white but also dark gray ...so maybe that could still work. Of course - in "the best case" it will be very readable. I think thats what we should aim for when we create an example project structure for the interactive figma prototype :-) We probably have to refine the project example scenario multiple times to add more details to show all the features of the "gig/exercise component" or rather "task messenger" component we are working on :-)
One idea is, that as a project manager i would want to expand the "next tasks" to see some more details to maybe understand or remind myself what they were about and then collapse them again. so what you are seeing here is many things. I can show some snippets i already posted on discord earlier. if you have things expanded like above and then you click into the empty space in front of it will "bookmark" or "pin" this task. now if you expand
so
what is the reason why somebody would want to pin something? imagine your project is to build an airport i don't know - or maybe you have the electric cables for that projector, but the point is, that if your project is large enough and you are working on one tiny part of it ... you might not care for the large overall structure of the project, so you want to PIN that particular task you are intereted in and forget about the rest for now :-) also - if you would expand sooooo many levels in the task tree menu, you would need to start scrolling to the left a lot, because it just doesn't fit onto a mobile screen anymore. |
|
feedback
Great worklogs.
This is just an example, but if you could edit your previous worklogs to update that and then also update the top level |
|
feedback FEEDBACKFirst - can we start making a glossary document? :-) I think defining all
and then consistently using those names will help us a lot. 01. copy link
02. task (tree) menu
I assume your definition of "todo" is a task that does not have a chat or sub tasks Anyway... GOAL:
The last point does not mean users can do everything, it is often READ ONLY until they get accepted to also have write access It is because this app should support any kind of project, from a grocery shopping list to running an entire country. So - one major goal of the app is to support this - which is why we aim for solving it and not avoiding it :-) note: because it is open source, somebody can later take the code and make a variation that has also the privacy/closed features, 03. roles
Elsewhere we still say If you feel that "contractor" is different from "client", then let me know. So basically - there are no hierarchies anymore as in: "a contractor is also a worker but higher than a worker of a contractor" 04. apply / fund buttons
When somebody creates an
Because maybe somebody creates a task and:
So basically the "create link" (which you just call assign), should probably be called "invite" 05. candidatesmaybe you do remember how we did the "application phase" all public on github with It will be a tool to support our specific peer to peer open source ecosystem. 06. application flow for candidates
But maybe the whole task tree menu can still be explored and if any task has nobody assigned and has an open invite link,
We need a flow for both (apply and fund) and i like the flow for apply where the main action you can do is chatting :-) So imagine ralf applied for Ralf can see already in the chat that Ralf can also explore the planned, outputs see where those outputs are used as inputs ...and so on :-) 07. actions for candidates or workers
That way we can get rid of lots of visual clutter and actions will always be triggered from the bottom action bar 08. action input bar
ACTIONS:
We will have to think systematically how to smartly organise and group actions Also, i think it is realistic, that a i think this should go hand in hand with designing a very smart
09. chat input barI think that was already part of my last feedback. Can we try that too? I think i shared that already in the last feedback videos. Also - on the start screen and later in the chat and generally everywhere. 10. empty start screen
Now if you are new and your "home screen" is empty, then it can show the video instead that explains how to use the app. I believe we should merge the explanatory video and the empty task screen :-) 11. worker flow
Contentwise or feature/functionality wise i agree with this flow. BUT: notifications will be shown outside of the app (e.g. mobile phone or browser notifications)
So, please check the feedback for "mutual agreements" or "contract amendments" below. 12. create task form
so here a user can "Create task" to finalize the form, but then they can still create sub tasks consider 1: consider 2: I like this screen. It shows the current task tree menu (e.g. only the roadmpaping task) When it comes to input documents, a user can always upload/link to existing documents, but at least text and propable markdown files we as input documents can be created inside the app, so that it is easy to add a "Task description" document as input document if necessary 13. tasks vs todosok i think we need to get one thing right with our word definitions. On github there is no such thing as a distinction of "todos" and "categories/tasks"
on github, every checkbox todo can be turned into a seperate github issue and no matter if:
They should all be the same thing - they are all "tasks"
Our goal of minimalism includes conceptual minimalism. Some tasks can be used by a user to just represent some sort of "grouping" of tasks, like (UI/UX design) or (roadmapping) On the other hand, the same is true for todo with no sub tasks in that it can get its own payment/time estimation and so on... Let's not distinguish between those things. 14.
|
|
feedback
In summary - that looks a bit unclear in terms of what belongs to what Also, imagine:
It could be, that "design searchbar" has no inputs and "design button" has outputs which include the inputs of design searchbar, or
OK - you say
|
|
feedback
The quoted messages (if more than one) should probably have a optional top section of the message to display a bit of the quoted messasge and then some sort of mini navbar or ways to expand the full message or jump to it and move between the current message and all related messages.
Basically - given we are dealing with professionals and work (especially programmers) and we want to be efficient and we will all be power users (because casual users will stick to tiktok/insta/whatsapp/...) i really want to see the "worst case" when a conversation gets really involved and densly packed with information so we need to utilize every last inch of screen estate to have all information available while interacting.
Otherwise: I hope we can first create some or many example message flows that fill the message log with messages in different scenario and optimize it like mad ...and we just assume all actions needed will somehow be magically available in the action bar and we can make a list of them, but we can optimize the details of how those actions will be available in the action bar later. But quoting, selecting, responding to messages and scrolling through messages and see all the details around those and navigating between quoted messages, etc... i'd like to nail that. In this context we can also go through all the different scenarios, like
Those kinds of things...
regarding actions once we have that, we can then do another iteration and try to get the "action bar" in order. What is meant by that is, that if the user had a live conference call (audio only or video - maybe with screen sharing, etc...) that is also causing a message entry in the chat log that records when and how long that video/audio call lasted and technically this allows both sides to download the recorded audio/video stream or re-watch it later on. It is also possible to make a message and e.g. "QUOTE" that video call and then maybe write a summary of what has been discussed in that call - maybe even make it a worklog and request the other party to accept the tasks that were derived in that video call. It could also be, that such a type of message can be expanded and has a few attachements (like notes that were taken during the video call) ... If you want to see how this will work, you can check https://keet.io (which is a p2p video conferencing alternative to zoom and the likes. It already works and uses the same technology we will be using for our app. BUT: let's not design yet the video call or audio call itself, but just assume it happened and is over now ...and how will the message that represents that video/audio call look like. It is just yet another type of message.
|
|
feedback if a user selects a message, they should have an option to auto-collapse all messages not part of the message history of quoted messages, e.g. if message3 and in between things should be collapsed like in the screenshot, |
|
not bad, but would be good to post worklogs more often instead of a long list of them all at once :-) |
|
feedback
Thank you for the worklogs. 1
Also, the "action bar" is a separate component and probably shows when a message is selected, 2
3
So if every worklog is supposed to solve one task, it basically solves a task room. It sounds very extreme, but i think we should aim for that and be radical. If a worklog solves some stuff, but not the entire task, then a worklog could propose a sub task with an output and solve it immediately, which means, if multiple worklogs are being submitted and all of them do not solve the task yet (e.g. your worklogs now do not solve the "gig/exercise" github issue yet, then they would propose "sub task rooms" with "outputs" and once i accept the submitted worklogs those tasks get created and immediately finished with the outputs being accepted. I would usually not accept them until you make a plan where or how you would use those outputs as inputs to the next tasks you plan to work on. In that style we get the goal orientedness into the task messenger. 4
The worklog message is not bad, but: I like that things can expand/collapse, but i think it is bad to add labels to the section.
those things are self explanatory. A task is 🔲 or ☑️ which indicates that something is done and the task itself has a task name that describes what it does. An output file has a name too and also a file extension or something that makes clear that it is an output and we also know it is ❓ or 📦 so that is self explanatory too. Lastly the list of questions will all end with a Also I really thinkg we should literally cut/paste the same visuals we use in the task menu or rather re-use the same "task menu" component inside a worklog messages to show all the tasks, inputs and outputs related to that worklog message inside the message instead of inventing a different style of visualizing tasks and outputs inside a worklog message. So this is the result of iterating the design of the worklog message, but it is not in the row below the previous iteration of this component, so for me, without watching your video, it is super hard to find. I literally have to scroll around, check things and guess that this is the second iteration and not the first..which one comes first, which one comes after? is that the only version? is there another somewhere else on the figma canvas? ...let's improve the structure. otherwise: Now the same goes for preview. preview of attachements (outputs) should only show on demand and not by default.
What I mean by that is, right now for example:
But in our future task messenger we can be a lot more strict about things, which means:
This style of working keeps the main chat clean and encourages to create many sub tasks on the fly and if a worklog for that sub tasks does not get accepted right away, the discussion can continue in that new sub task channel until the revised worklog is accepted which is when the task room gets finished and closed. GENERAL PATTERN: Sub Tasks are just sub contracts with sub contract amendment logs. |
|
feedback
1You say the feedback should be part of the worklog message, but as the general pattern mentioned earlier, here a little bit of technical background of how literally every message will look like in terms of data structure: const messageA = { // example
head: ['david', 'alex', 15],
refs: { cause: ['alex', 'david', 4] },
type: 'worklog',
data: { questions: [/* ... */], comment: 'hope you like it' }
}
const message6 = { // example
head: ['alex', 'david', 12],
refs: { cause: ['david', 'alex', 15], worklog: ['david', 'alex', 15] },
type: 'feedback',
data: { action: 'accept', comment: 'good job', answers: [/*...*/] }
}So we are definitely dealing with distinct messages. Again - this is all for wizardamigos, so using the UI/UX should educate about the technical structure that is underneath the visual interface. Also: a worklog marks the task in the task menu as done once it is accepted by the client (=task author) 2
As an author, any action taken, will provide a form where the client should send a comment or answers along with their feedback message to answer the question in any case, whethere they rejected/accepted offered a change proposal to the existing worklog.
And the client would respond with a feedback message to accept/change/reject those. This makes each message simpler and not stuffing too many purposes into a single message. guiding principles:
3
We would first need to decide a strict technical criteria how and when we group messages and is there a possibility for intermediate unrelated messages that can be send in between and what happens with those? Anyway, if we have a clear concept, then i would call those not "summary messages" but: Now think again - IF (as said earlier)... a worklog always basically closes a task chat, which means we are really radical, because we make the tool and we can and it really helps a lot by working actively and a lot with the tasks (which is something we sadly dont do at the moment), THEN: a task room that gets closed with a worklog is already a "converation summary" around that specific task. So do we need more than that? We don't do it because it is too much work, but a messenger could make it effortless and the advantage would be an up-to-date task structure that is really heavily in use and shows us our progress quite well. 4Thanks for mentioning you are gonna add the "time spent" to each worklog. You mentioned you feel like you did not miss anything in that list, I did not see how a provider can propose a list o I also did not see an additional free form text - just the section labeled as "open questions". now again - thinking about what is written above in this github feedback comment of mine - maybe we should separate those additioanl worklog message type features from the list below which i just described into separate message types and then a provider (=worker) can submit a and the protocol for changes looks like ⛓CHANGED: |
|
feedback This is the figma canvas. Of course it does not include all the previous parts containing our iteration on the But on top of that - from a zoomed out high level view, this figma canvas does not look like a table, but more like a mess 😅
👍 for the versions, but still timestamps are missing. this way we only need a single large figma canvas that contains everything ...and if that is too much for figma, we can maybe outsource some component columns to different pages, but if possible i would want to avoid that.
We can create some github issue tasks with the output of a new version controlled figma file to re-build the figma history in this very precise and controlled manner. so, in programming people strictly work with |
|
feedback
1 worklog message
more specifically: 2 feedback input
also 3 feedback flow componentThis component might exist with a first iteration before the individual parts exist. ...but then we discuss it and we roughly agree and then maybe we make the individual components included in this flow, which are the "worklog message" and maybe the "worklog actions" a user can select and a "feedback input field" component and make columns that also have a first iteration of those ...and then afterwards we can come back to the "feedback flow component" that puts all of that together and we make a second iteration that refines it. 4 worklog feedback conversationThis is essentially the continuation of the "feedback flow", so technically, once we improve the .... or not, maybe the "feedback flow component" is a sub component of the more complex "worklog-feedback-conversation component". I think we will figure that out while working on the iterations :-)
ninas feedback message has it's own avatar + identicon + timestamp, so it should be separate messages. But maybe those messages can be collapsed into some sort of third component which includes a series of related worklog/feedback messages and we call that a in general |
|
feedback
So the Let people just send multiple different type of messages or use the "batch actions" feature to create a complex message that includes multiple connected messages of different types. Also - again, for tasks, outputs and time we should re-use the "task menu" as much as possible and have it more like an "editable file explorer" (like vscode file tree explorer allows change actions) The whole change is then proposed in a message and if the worklog is
note:*
note: this component will also be used in the for example this part of the worklog input form, i imagine more similar to the task menu, which means i would click on the "task name" listed further above in the worklog, the one which i finished and log time for and now, because that task is selected, the "bottom action bar" would show me an action "add output" or alternatively, because a specific task is already selected and the planned outputs can be expanded, just like in the task menu ...we can now click on one of those planned outputs to select it and that will show the "upload" or "link" action in the bottom action bar and if i click it and select a file or paste or type a link, that will then update the planned output to done output with the uploaded or linked document .... That would feel more natural and in line with our general concept of:
=> and here in the worklog form we do it the same way again like everywhere else - so nothing new to learn by the user and we can re-use the existing action bar and task menu components.
|
|
feedback
again, watching all the videos.
👍 for having the time included Again further more, the grouping of worklogs and feedbacks needs to change too - see previous feedback comments above :-) So basically, one take away:
|
@todo@input📦what have we built hackmdfrom History : How it all started #45@input📦history content slidesfrom History : How it all started #45@input📦brief summary slide deckfrom project brief @mimi_uxui-dev #42@input📦concept outline descriptionfrom get familiar with wizardamigos #46@input📦wizard amigos summary pagefrom project brief @Hornet004 #102@output📦Figma Link1fromcomment@input📦Figma Link1@output📦 Figma Link2 fromcomment@input📦Figma Link2@output📦 Figma Link3 fromcomment@input❓idea came fromcontext 59#comment so what is a QUIZ in this context? section@input❓idea came from59#comment section B@input❓idea came from59#comment section A , first todo@output🏭 hackmd file@output❓gig/exercise data generator slides@output❓gig/exercise data generator wireframes@output❓gig/exercise data generator linked markdown file per slide in "./slides/<slidename>.md"@output❓gig/exercise viewer slides@output❓gig/exercise viewer wireframes@output❓gig/exercise viewer linked markdown file per slide in "./slides/<slidename>.md"@output❓gig/exercise editor slides@output❓gig/exercise editor wireframes@output❓gig/exercise editor linked markdown file per slide in "./slides/<slidename>.md"@inforegarding bounty programs and gigs in general, here are pages that do those:
more infos
the only difference between an
exerciseand agigis, that the exercise is posted by a bot and the "gig chat" of an exercise is about talking to a bot and the payment at the end is 0 but the learners has a finished exercise, so UI wise those are almost identical and can be re-used mostly. Technically an exercise can even have a real payment attached and a gig could technically also be managed by a bot, so the distinction is not super clear and for a learner it might not even matter.Layout is a special instance of workshop tools concept & design #60
Get paid
Not Real Moneymaybe points? when the task is anexerciseinstead of agigusers can do messages of type comment (like on GitHub issues)
Get Paid Real Money
“chat actions” (= type of messages), like: a worklog messages (where you record/upload a short screencast video) + a feedback message + probably some other more contract related type of messages to set, review, accept, confirm, etc… work and issue payments
some gigs can be pro bono maybe its something not executable, like a question or just a thumbs up, maybe that has to go into the chat and you can subscribe to answers there too ...or the gig is to answer you the question and the bounty is 0
the gig view will let you do messages of type comment (like on GitHub issues), but also some other “chat actions” (= type of messages), like: a worklog messages (where you record/upload a short screencast video) + a feedback message + probably some other more contract related type of messages to set, review, accept, confirm, etc… work and issue payments
CONTRACTUAL
Another thing is, that clicking a "custom action" like apply for a gig just means some sort of special "chat message" (or "chat action")
In fact, when doing a gig and talking to the author of the gig and working on it, there are many such "chat actions", for example:
So when a user clicks "APPLY" on a gig, thats the first message in that chat.
The response of the author could be an accept/reject or some text before the accept/reject is issued
once accepted, maybe the gig disappears from the public list or is in progress and others are then not able to apply
But if the author rejects, the gig is again open for others
Now details whether that discussion is public or private is for later and for now i would all keep it open, because thats how we work and how github works and its for now one less thing to worry about.
Also: other applicants can already learn from previous applicants and the conversations instead of going through all the questions again and again :-)
Infoclicking on "submit feedback" is basically opening or making a gig and the gig can be closed/removed by the maintainers, also like every gig, a bounty can be attached or maybe other users who want to submit feedback see an existing similar gig feedback and just add some more information and add some more bounty, other kinds of feeedback would probably instead just be a "chat message", not in the workshop chat, but in the chat of maintainers. submitting a feedback is opening or participating with info or bounty in an existing feedback gigThe text was updated successfully, but these errors were encountered: