Aktrea

aktrea

ADA: A Powerful Data Augmentation Technique for Improved Regression Robustness

HyperTransformer: Conclusion and References

This is the first part of a deeper dive into Ollama and things that I have learned about local LLMs and how you can use them for inference-based applications. In this post, you will learn about — How to use Ollama How to create your own model in Ollama Using Ollama to build a chatbot To understand the basics of LLMs (including Local LLMs), you can refer to my previous post on this topic . here First, Some Background In the space of local LLMs, I first ran into LMStudio. While the app itself is easy to use, I liked the simplicity and maneuverability that Ollama provides. To learn more about Ollama you can go . here tl;dr: Ollama hosts its own curated list of models that you have access to. You can download these models to your local machine, and then interact with those models through a command line prompt. Alternatively, when you run the model, Ollama also runs an inference server hosted at port 11434 (by default) that you can interact with by way of APIs and other libraries like Langchain. As of this post, Ollama has 74 models, which also include categories like embedding models. How to Use Ollama Ollama for the OS of your choice. Once you do that, you run the command to confirm it’s working. It should show you the help menu — Download ollama Usage:
  ollama [flags]
  ollama [command]

Available Commands:
  serve       Start ollama
  create      Create a model from a Modelfile
  show        Show information for a model
  run         Run a model
  pull        Pull a model from a registry
  push        Push a model to a registry
  list        List models
  cp          Copy a model
  rm          Remove a model
  help        Help about any command

Flags:
  -h, --help      help for ollama
  -v, --version   Show version information

Use "ollama [command] --help" for more information about a command. To use any model, you first need to “pull” them from Ollama, much like you would pull down an image from Dockerhub (if you have used that in the past) or something like Elastic Container Registry (ECR). Ollama ships with some default models (like which is Facebook’s open-source LLM) which you can see by running. llama2 ollama list Select the model (let’s say ) that you would like to interact with from the . You can now pull down this model by running the command phi Ollama library page ollama pull phi Once the download is complete, you can check to see whether the model is available locally by running — ollama list Now that the model is available, it is ready to be run with. You can run a model using the command — ollama run phi The accuracy of the answers isn’t always top-notch, but you can address that by selecting different models or perhaps doing some fine-tuning or implementing a RAG-like solution on your own to improve accuracy. What I have demonstrated above is how you can use Ollama models using the command line prompt. However, if you check the inference server that Llama has running you can see that there are programmatic ways of accessing this by hitting port 11434. If you wanted to use Langchain to access your Ollama model, you can use something like — from langchain_community.llms import Ollama
from langchain.chains import RetrievalQA

prompt = "What is the difference between an adverb and an adjective?"
llm = Ollama(model="mistral")
qa = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=retriever,
    return_source_documents=True,
)
response = qa(prompt) How to Create Your Own Model in Ollama You can also create your own model variant using the concept of in Ollama. For more parameters to configure in your Modelfile, you can look at these docs. Modelfile Example Modelfile — # Downloaded from Hugging Face https://huggingface.co/TheBloke/finance-LLM-GGUF/tree/main
FROM "./finance-llm-13b.Q4_K_M.gguf"

PARAMETER temperature 0.001

PARAMETER top_k 20

TEMPLATE """
{{.Prompt}}
"""

# set the system message
SYSTEM """
You are Warren Buffet. Answer as Buffet only, and do so in short sentences.
""" Once you have the Modelfile, you can create your model using ollama create arjunrao87/financellm -f Modelfile where is the name of your LLM model and would be replaced by your ollama.com username (which also acts as the namespace of your online ollama registry). At this point, you can use your created model like any other model on Ollama. financellm arjunrao87 You can also choose to push your model to the remote ollama registry. To make this happen, you need to Create your account on ollama.com Add a new model Have the public keys set up to allow you to push models from your remote machine. Once you have created your local llm, you can push it to the ollama registry using — ollama push arjunrao87/financellm 🦄 Now, let’s get to the good part. Using Ollama to Build a Chatbot During my quest to use Ollama, one of the more pleasant discoveries was this ecosystem of Python-based web application builders that I came across. can be used to build a full-fledged chatbot like ChatGPT. As their page says, Chainlit Chainlit is an open-source Python package to build production ready Conversational AI I walked through a few of the Chainlit tutorials to get a handle on what you can do with chainlit, which includes things like creating sequences of tasks (called “steps”), enabling buttons and actions, sending images, and all kinds of things. You can follow this part of my journey . here Once I got the hang of Chainlit, I wanted to put together a straightforward chatbot that basically used Ollama so that I could use a local LLM to chat with (instead of say ChatGPT or Claude). With less than 50 lines of code, you can do that using Chainlit + Ollama. Isn’t that crazy? Chainlit as a library is super straightforward to use. I also used Langchain for using and interacting with Ollama. from langchain_community.llms import Ollama
from langchain.prompts import ChatPromptTemplate
import chainlit as cl The next step is to define how you want the loading screen of the chatbot to look, by using the decorator of chainlit — @cl.on_chat_start @cl.on_chat_start
async def on_chat_start():
    elements = [cl.Image(name="image1", display="inline", path="assets/gemma.jpeg")]
    await cl.Message(
        content="Hello there, I am Gemma. How can I help you?", elements=elements
    ).send()
    ....
    .... The interface is what Chainlit uses to send responses back to the UI. You can construct messages with the simple key, and then you can embellish it with things like which, in my case, I have added an to show an image when the user first logs in. Message content elements Image The next step is to invoke Langchain to instantiate Ollama (with the model of your choice), and construct the prompt template. The usage of the is to mostly maintain the separation of user contexts and histories, which just for the purposes of running a quick demo, is not strictly required. cl.user_session Chain is a Langchain interface called that is used to create custom chains. You can read more about that . Runnable here @cl.on_chat_start
async def on_chat_start():
   ....
   ....
    model = Ollama(model="mistral")
    prompt = ChatPromptTemplate.from_messages(
        [
            (
                "system",
                "You are a knowledgeable historian who answers super concisely",
            ),
            ("human", "{question}"),
        ]
    )
    chain = prompt | model
    cl.user_session.set("chain", chain) Now, you have all the pieces to have a chatbot UI and accept user inputs. What do you do with the prompts the user provides? You will use the handler from Chainlit to do something with the message the user provided. @cl.on_message @cl.on_message
async def on_message(message: cl.Message):
    chain = cl.user_session.get("chain")
    msg = cl.Message(content="")
    async for chunk in chain.astream(
        {"question": message.content},
    ):
        await msg.stream_token(chunk)
    await msg.send() as the docs suggest “stream back chunks of the response async” which is what we want for our bot. chain.astream That is really it. A few imports, a couple of functions, a little bit of sugar, and you have a functional chatbot. For the full code, you can see my . GitHub 👏 If this content is interesting to you, hit that button or subscribe to my newsletter here → . It gives me the feedback that I need to do more or less of something! Thanks ❤️ https://a1engineering.beehiiv.com/subscribe Also published here

How to Use Ollama: Hands-On With Local LLMs and Building a Chatbot

কীভাবে ওল্লামা ব্যবহার করবেন: স্থানীয় LLM-এর সাথে হাত মিলিয়ে এবং একটি চ্যাটবট তৈরি করা

So verwenden Sie Ollama: Praktische Arbeit mit lokalen LLMs und Aufbau eines Chatbots

Cómo utilizar Ollama: práctica con LLM locales y creación de un chatbot

Comment utiliser Ollama : pratique avec les LLM locaux et création d'un chatbot

ओलामा का उपयोग कैसे करें: स्थानीय एलएलएम के साथ व्यावहारिक व्यवहार और एक चैटबॉट का निर्माण

Ollama の使用方法: ローカル LLM の実践とチャットボットの構築

Ollama 사용 방법: 현지 LLM 실습 및 챗봇 구축

Como usar o Ollama: prática com LLMs locais e construção de um chatbot

Как использовать Ollama: практический опыт работы с местными LLM и создание чат-бота

Ollama Nasıl Kullanılır: Yerel Yüksek Lisans Dereceleri ile Uygulamalı Çalışma ve Bir Chatbot Oluşturma

Cách sử dụng Ollama: Thực hành với LLM địa phương và xây dựng Chatbot

如何使用 Ollama：与当地法学硕士一起实践并构建聊天机器人

Transductive Learning for Textual Few-Shot: Limitations, Acknowledgements, & References

THE STARS OF SUMMER

Lately, it seems that not a week goes by without fresh news of a vulnerability that could unleash a wave of attacks on servers and devices around the world. But some weeks are worse than others. On December 10th, the studio behind the ever-popular sandbox game Minecraft published a blog post detailing a bug . The bug would allow an attacker to take control of a machine running the vulnerable software. it identified in Log4j The problem is that Log4j is one of the most-used open-source libraries ever created, and that means there by the threat. But the announcement wasn't bad news for everyone. WordPress site owners, for example, breathed a heavy sigh of relief that the isn't on the list of software vulnerable to the Log4j threat. aren't many servers or devices that aren't affected 18-year-old CMS That doesn't mean, however, that WordPress site owners should relax, though. Right around the same time that the Log4j catastrophe started hitting the headlines, another threat emerged that's no less serious. And it's aimed squarely at WordPress websites. As of the 10th, reports indicated that at least 1.6 million WordPress sites were under active attack, and that could just be the beginning. The attackers are trying to exploit a variety of vulnerable WordPress plugins and themes. And when they succeed, they gain full administrator access to the affected website. So, site administrators have their work cut out for them to see if their sites are vulnerable to attack. And to help them do it here's a list of the known vulnerable plugins and themes, and an overview of what to do to secure a vulnerable site. The Affected Plugins One of the reasons the current attack on WordPress sites is so widespread is that the attackers are targeting a handful of vulnerabilities at once instead of a single one. And frustratingly, some of the vulnerabilities received patches as early as 2018 – which indicates a whole lot of site administrators who haven't kept up with the available plugin updates. So far, the list of plugins being targeted include: version 2.3 and below PublishPress Capabilities version 2.0.10 and below Kiwi Social Share version 4.14.3 and below Pinterest Automatic version 3.53.2 and below WordPress Automatic The good news about this list is that every one of the affected plugins has a patch available that fixes the vulnerability. That means WordPress sites using them can update today and prevent attackers from exploiting their sites if it hasn't happened already. The Affected Templates Unfortunately, plugins aren't the only things that the attackers are targeting right now. They're also targeting a vulnerability in the , which is a common set of underlying code that a variety of WordPress themes rely on. But again, the vast majority of the affected themes have patches available that correct the problem that makes them vulnerable. All but one, that is. Epsilon Framework The affected site themes are: Activello version 1.4.0 and below Affluent versions below 1.1.0 Allegiant version 1.2.5 Antreas version 1.0.4 and below Bonkers version 1.0.5 and below Brilliance version 1.2.9 and below Illdy version 2.1.4 and below MedZone Lite version 1.2.4 NatureMag Lite all versions – no patch available NewsMag version 2.4.1 and below Newspaper X version 1.3.1 and below Pixova Lite version 2.0.5 and below Regina Lite version 2.0.4 and below Shapely version 1.2.7 and below Transcend version 1.1.8 and below With such a long list of vulnerable themes, the scope of the potential attack is far larger than what security researchers have recorded so far. But updating the affected themes to the most recent version can prevent attackers from gaining access to a previously vulnerable site. The only known exception is the NatureMag Lite theme. So far, there's no patch available for that one. That means sites using it should replace it with a different theme immediately, and remove the vulnerable version from their WordPress installation. Unfortunately, such drastic action is the only thing users of that particular theme can do to secure their sites right now. How to Spot the Exploit Because some of the vulnerabilities listed here aren't new, any site that used any of the vulnerable plugins or themes may have already gotten hit by the attack. And although many webmasters assume that seeing no physical changes to their site's contents is a sign that it's safe, they shouldn't dismiss the threat so easily. That's because the attackers aren't necessarily trying to deface websites. They're trying to give themselves access to their administrative consoles and to do so without getting caught. From there, they could use that access to harvest user data or make other unauthorized changes to the site's underlying code. The good news is that the way the attackers are doing this leaves traces that webmasters can find if they know what they're looking for. What they're doing is enabling the setting "users_can_register" and altering the "default_role" setting to "Administrator". From that moment forward, every new user account added to an affected site would have administrative access by default. So, the first thing to do to see if a site's been compromised is to go to the general setting page of the WordPress administrative console, at: http://yourdomainname.com/wp-admin/options-general.php On that page, make sure that user registration is unchecked (unless your site allows registrations on purpose), and that the default role is set to " " or whatever for the site in question. If either of the options were altered from the correct settings, there's a good chance the site's been hacked. Subscriber role is appropriate What to Do Next In this case, there are only two real options for WordPress site owners if they discover evidence that an attacker has gained administrator access to their site. For sites that don't collect user data or that aren't mission-critical (like personal blogs and the like), it may suffice to go through the site's user list and remove any accounts created without authorization. At the very least, this will cut off the attacker's administrative access going forward. The only problem then is trying to figure out if any other changes have been made to the site itself. The trouble is that someone with administrative access could have made changes to the site's underlying code that are near-impossible to detect. These attacks can hinder various on-site operations. For businesses, the problem could affect crucial processes, including the and even customer data privacy. organization of expense categories However, for some people, the prospect of such undetected changes isn't a big deal. But unless the affected site is so unimportant that it wouldn't matter if it got defaced, looted, or destroyed, leaving well enough alone isn't a viable option. So, most owners of compromised websites will want to reinstall WordPress and restore their content from a backup. In a perfect world, a backup from before the vulnerable plugin or theme was added is the best bet – but in the real world, the age of the vulnerabilities means that may not be possible. Cleaning Up After a Hack The first step in cleaning up a hacked WordPress site for which no clean backup is available is a counterintuitive one. It's to take of the site as it exists before attempting a cleanup. This is to reduce the chances of doing any irreparable damage or losing irreplaceable content in the process of cleaning up the site. a complete backup The next step is to get to work rolling the WordPress site back to its defaults. To do so: Make a list of the plugins in use and then delete the contents of the site's "wp-content/plugins/" folder. This will eliminate the local copies of the plugins that may have been altered by an attacker. Once this is complete, re-download and reinstall the necessary plugins. Remove all installed themes that aren't in use and delete their associated folders in the "wp-content/themes" directory. Then, download a fresh copy of the theme that's in use and replace its files in its installation folder. This will eliminate any changes the attacker may have made to the site's theme. Examine the site's "wp-admin" and "wp-includes" directories to check for any new or updated files. Most of the time, the files in those directories don't change except when updating WordPress versions. So, if anything appears suspicious, the best option is to reinstall the current WordPress version from the administration dashboard. Then, delete any files in those folders that don't bear the date and time of the reinstallation. Check the site's storage location for any directories that contain backup copies of the site. If any exist, delete them. Such copies may be accessible to the web and can provide an attacker with backdoor access into the current public-facing version of the site. Stay Up to Date Most WordPress site owners – if they act fast – won't have to do anything but update their plugins and themes to keep their site secure. But for the unlucky, a complete site reinstallation may be the only way to undo the potential damage caused by this latest wide-ranging WordPress attack. And after doing that, it's a safe bet that affected webmasters won't forget to update their site plugins and themes going forward. Doing that is the easiest way to keep a WordPress site safe from harm, and it sure beats the alternative.

The Log4j Bug Can't Hurt WordPress - But There's an Ongoing Attack That Can

Many developers are familiar with the situation like “ ”. You have to spend time and deal with the details already considered by another colleague. How to make it take a less amount of time? To achieve this, pay attention to a process of writing descriptions for Pull Requests (known as “PRs”) and Merge Requests (known as “MRs”). This article will focus on the content of the PR description without any explanation of coding since each project has its own coding-related specifications and requirements. where did this code fragment come from and why is it needed? Here is the list of topics that are covered in the article: Why is the description for Pull Request important and useful? What should a useful description of Pull Request contain? Which action helps writing a proper Pull Request description? Why the description for Pull Request is important and useful First of all, let’s try to understand why it is better to pay attention to the description for PR. Working on a project is a long path that’s divided into short segments. The beginning of each segment is a task, the steps are commits, and the end is PR. The importance of PR is rising when you start to realize that PR is the result of your work on the task. Superficially, it seems that the most important part is the commits with code that introduces functionality, optimizes the work of the final product. However, there is also another thing — the context of the changes that you apply to the product and the reasoning. The context implies your rationale for the chosen implementation method, the selected tools, the encountered issues, and the dilemmas. Providing context for PR is useful since the task itself and its discussion might be not sufficient enough to understand the full picture of the changes. It is good, when the discussion was conducted in the issue tracker or, verbally or in the chat, and was written in the form of short results. If not, then you will have to answer the questions like “where does this code come from and why is it needed here?” As a reviewer, I don’t feel joy during a PR review if I have to spend extra time to understand the logic of code and commits, because the author did not bother to write a proper description. When the coding part is done, the author of the changes could dedicate some time to the general description of PR, while everything is still fresh in memory. In this way, the author would save the time and effort of the project team. Let’s list the project members, who can benefit from the properly described PR: no longer have to guess what you wanted to achieve with the changes. There is no longer a need to spend time asking questions, like or “ ” Reviewers “Why did you pick this implementation path and not another?” Why did you choose the particular approach or selected some dependency? while looking at your commit can find a PR with a description of the changes made and a link to the task with related discussions. In the end, this will help to avoid bugs, since if your code needs to be altered in some way, colleagues can find out the requirements for its logic and pay attention to the relevant details. Project colleagues won’t need to answer additional questions about the implemented changes. In such cases, you can always refer to the description, where the most important points have already been clarified. This becomes even more relevant over time — since after like six months, it will be difficult to remember why the particular change was made. Anyway, there is no need to do that if the changes are backed up by a meaningful description. You This all leads to a conclusion: The description of PR is as valuable as the task ticket. Presenting the results of the work in the description for PR is important and useful, as it will save precious time and energy for the future. What should a useful description of Pull Request contain Now let’s consider important parts to cover to write a useful description for PR. Title Start with the title — it should reflect the essence of the changes. If there is a corresponding task or ticket, then the PR title can overlap with it. In such a case, a prefix with the task number should be added. SLI , SLI - Support reading input STDIN
SLI - Bugfix memory leak when input is supplied via STDIN -001 -002 for from -002 for The title should preferably be informative and short enough. Related tasks Tasks and tickets that are related to or will be solved by the PR must be provided. Better to provide them as a list with links to tickets in the tracker. In MarkDown, it looks the following way: ## Related tasks
- [SLI ](http: - [SLI ](http: -001 //my.issue.tracker/project/SLI-001) -002 //my.issue.tracker/project/SLI-002) Such an approach greatly simplifies navigation. For tasks that are located on GitHub and GitLab, there are special phrases that can be used in PR to close the referenced issues ( and ). manual for GH manual for GL Dependence on other PR If the PR is based on other open PRs that should be reviewed first, then they should be listed. This also applies to PRs for used packages and dependencies. Here is the example in MarkDown: ## Depends on
- # (other opened PR same repository)
- dependency# (other PR the other related repository) 3 in 55 in This will optimize the PR review process and save time for reviewers. If your PR does not depend on anything, skip the section. Premise This section is dedicated to preliminary research or other things that were preceding the applied changes. The following should be covered here: If you made a choice between possible packages and chose the most suitable one, then you should provide links to each package, then describe its “pros and cons” for solving the particular problem. You should also state the final reason why you have chosen a specific package for the integration into the project. If there was research about a task-related topic or an investigation for a different implementation approach, then you should provide links to the articles that were helpful in understanding the solution. You can also describe key points that will help to understand the changes that will follow. If you discovered that the existing code is disturbing you, then it should be outlined. If you were forced to refactor some function due to it being poorly implemented or affecting your implementation in some way, then it would be better to explain why such change was considered as necessary. Brief results of discussions with the team, which will help to understand why certain decisions were made. An example may look like following: ## Premise
As we have grammar description and access to an 
assembly code even AST, I considered to use 
PEG-based parser to generate custom AST assembly code, then use adapter to make it 
compatible current ASTReader processing logic. 
As prerequisites I from from with 've looked through the following 
packages:

- https://github.com/navstev0/nodebnf (npm) - I 
tried and in the end came to the conclusion, that 
it is not so stable to be used for our needs. Also, 
lacks proper documentation.

- https://github.com/lys-lang/node-ebnf (npm) - Has 
proper documentation and TypeScript definitions. 
Also, has a useful online sandbox. Chosen for the 
further implementation. This section is used for general cases when it is necessary to present any information in a reasonable volume that the reviewer or any other colleague should know they begin the inspection of the changes of PR. If there is no such need, then the section should be skipped. before Changes The section should list the changes that are applied. If you previously described the details in the messages of commits, then you can reuse the text from there. If you think that some points require additional explanation, then you can indicate important information as sub-items. ## Changes
- Added dependency [ebnf](https: - Cleaned **package.json** some obsolete 
commands. Introduced to copy BNF-
files when post-install occurs.
- Introduced **src/ebnf** directory components 
to parse code strings by BNF definitions.
- Tweaked configuration to be able to work a set components.
- Introduced tests to cover functionality. //www.npmjs.com/package/ebnf). from `ebnf:update` with with new of new Here are some guidelines for formulating the contents for the section: Some changes are available via reviewing the diff. Therefore, do not micro-describe — GIT will do it for you. It is better to summarize the changes, stating their meaning. For instance: - The dependency versions are updated because they 
are very outdated and the security audit detected 
vulnerabilities.

- Files the X directory were deleted because the 
component that worked them was replaced another. They were no longer needed.

- The method was updated because the low-level API 
has changed, and because , the method no 
longer worked properly. in with with of this When justifying actions related to dependencies, do not hesitate to use links to releases, merged bug fixes or features — it is going to be very useful in the future. If you introduce a new class, function, method, or other routines, it is better to describe its purpose (or even better, do it in the doc block in front of its definition). Try to pay a bit more attention to the actions that cannot be covered by comments in files with the source code: moving files, deletions, automatic updates (dependency configuration, for example). Some additional features, that you also should be aware about: You can use the “task list” option that is available on and . The list items can thus be made interactive. GitHub GitLab For clarity reasons, do not hesitate to refer to the code segments that you mean. You can read how to do this (I was unable to find instructions for GitLab and will be glad if somebody will share the link). here for GitHub Concerns If you have any doubts or feel contradictory, regarding the implementation, then mention in PR. Feel free to state your concerns and ask for advice from project colleagues. Here is a short list of possible reason to mention: You are recently on a project or not yet experienced in using a particular technology. So far, you did what you could, but you are unsure if the implementation is reliable. You encountered an issue that you don’t know how to solve, and advice from your colleagues would be helpful. You encountered a lack of time or additional difficulties and left part of the functionality unimplemented by placing a “stub” in the code. Ask about suggestions or state that you could use a bit more time to finalize the work. You might suggest another more effective approach to implementation, but you don’t know whether it is worth applying now, or it would be better to postpone the implementation to a later stage of development (depending on the circumstances). Here is an example in Markdown: ## Concerns
It appears that the compiler is trimming spaces and 
reducing indentation within assembly code strings AST node. This causes inability to 
generate proper attributes custom AST by 
simple math. Also, is not fixable, because 
these dependencies are already released and can not 
be patched. Need to find another way to link to a top-level node. Currently, any node will have the same parent node. Maybe I in `Assembly` `src` for this `AssemblyIdentifier` `VariableDeclaration` `AssemblyItem` `src` as `Assembly` 'm missing 
something... I would appreciate any suggestions 
that will help in solving the situation. If you have not encountered problems, then you should omit the section. Notes This section lists all the aspects that are not obvious or are side effects. For example, you introduced a new build command that copies files, or used some kind of functionality with “magic numbers”. Better mention such things in advance, because the questions will be asked sooner or later anyway. Here are some examples: ## Notes
- This PR changes major package API, which would 
result a backward compatibility (BC) .

- When changes applied to grammar files, developer 
must run to copy updated 
grammar files to **dist in break `npm run ebnf:update` /**. Otherwise, components 
will not react to any changes. All grammar files 
are static assets, so they are not compiled or 
handled by **tsc** in any way.

- For some reason `process.stdin.fd` is not 
available in type definitions for the current node 
version. It seems that we should upgrade at some 
point. I resolved this via magic 
`fse.readFileSync(0, { encoding: "utf8" })` (as `0` 
should point to `STDIN` for each process) and left 
a comment with the reasoning. What actions can help to make a proper Pull Request description A few actions that will allow you to compose the useful PR description. Please note that GitHub and GitLab provide the ability to create a PR description template (instructions are provided and ). Discuss with the team if it is worth setting templates in advance. here for GH here for GL When writing code, . Well-written commit messages are one of the best sources for the “Changes” section. Do not forget to mention the ticket code from the tracker. Modern trackers (Atlassian Jira, for example) are able to collect data from connected project repositories and generate links to related commits and PR. think about how you will compose the commit messages Before creating a PR, . Create a PR with only two sections “Tasks” and “Changes” with a “Reserved” mark. Then . put yourself in place of a reviewer do a code review by yourself This will help to look at the changes from a new angle. Please note that a less experienced colleague may walkthrough with your changes after the merge. Ask yourself the question: . “To not waste time in the future, is it worth giving an additional explanation in the description?” Think about what things might raise questions in the long term. If more than two people are involved in the project, then colleagues can start asking questions. If you can answer some of them in advance — this is a good reason to expand the description of PR. Next, try to put yourself out of context a bit and . The project may need to be transferred to other developers. In this case, it will be necessary to write instructions. think about what other aspects that may be important to the reader Ask yourself, “Isn’t it better to state important things now, while everything is fresh in my memory?” Remember if some important implementation decisions were discussed with your colleagues verbally or on other resources. If discussions have taken place, then take a little time to describe the summary. Feel free to and which will help to understand the logic of changes or decisions made. provide links to useful articles that you have read Consider to . Pay attention to the possibility of using labels to highlight that your PR contains changes in dependencies, backward incompatibility, bug fixes, or new features. Labels increase the explicitness and help with the search (for example, finding all bug fixes becomes a matter of one click). make the description more explicit GitHub and GitLab allow you to use the entire MarkDown formatting arsenal (instructions are and ). Proper formatting and structure will help to facilitate readability and simplify the understanding of many things. If the changes were applied to the GUI, then consider to supply screenshots of GUI state “before” and “after” the changes. here for GH here for GL Remember that , in particular the “ChangeLog”, the “Release Notes”, the “Read Me”. For the first two, it is enough to indicate links to PRs, for “Read Me”, there is an ability to paste part of the content. well-described PRs are helping with writing project documentation By composing a meaningful description of PR, you will help yourself and your colleagues not to waste time re-reading the code before the release of the new version — it would be narrowed to looking through the merged PRs since the time of the last release. Conclusion With this article, I tried to highlight that a meaningful and well-formatted PR description that is as valuable as a properly described ticket. If you have written the code for several hours, then it is also worth dedicating half an hour to summarize the work. is a project document A habit to write good PR descriptions will greatly simplify the life for you and the project team, also saving a lot of time during reviews and discussions. Living examples Here are some of the PRs for an open-source project that can serve as an example: https://github.com/b-mueller/sabre/pull/93 https://github.com/b-mueller/sabre/pull/89 https://github.com/b-mueller/sabre/pull/71 Further reading Here are some additional articles, that are related and useful: https://hackernoon.com/no-description-provided-8d9e0f3a3abb https://blog.carbonfive.com/2020/01/06/why-write-good-pull-requests/ https://www.pullrequest.com/blog/writing-a-great-pull-request-description/ Previously published at https://blog.maddevs.io/how-to-make-a-proper-description-for-a-pull-request-5e1cbe9fb374

How to Create A Detailed Description for Your Pull Request

The Top 30 Salesforce Consulting Companies

Stories, News & Mentions about AKTREA

Aktrea’s Stories on HackerNoon